なぜ、PostgreSQLは「静かに」デッドロックを検知するのか
PostgreSQLのアーキテクチャを深く掘り下げていると、時折「なぜこのデータベースはこれほどまでに堅牢なのか」と溜息が出るような設計に出会うことがあります。その一つが、バックグラウンドプロセスとして静かに、しかし冷徹に働いている「デッドロック検出器（Deadlock Detector）」です。
多くのエンジニアにとって、デッドロックは「運悪く遭遇するエラー」かもしれません。しかし、その裏側で何が起きているのかを知ることは、PostgreSQLのトランザクション管理という迷宮を解き明かす鍵になります。
検出器の「怠慢」がもたらすパフォーマンスの恩恵
まず、誤解を解いておきましょう。PostgreSQLのデッドロック検出は、リアルタイムではありません。トランザクションがロックを要求するたびに、即座にグラフを走査して循環参照をチェックするような重い処理は行われていないのです。
もしすべてのロック待ちで全走査を行えば、スループットは目に見えて低下します。PostgreSQLの賢いところは、「まずは待ちに入る」という戦略をとっている点です。
具体的には、`deadlock_timeout`（デフォルト1秒）という猶予期間が設けられています。あるトランザクションがロック待ちに入り、この時間が経過してもなおロックが解除されない場合、初めて「おや、これは長すぎる。もしかしてデッドロックか？」と検出器が重い腰を上げます。この「即座にチェックしない」という判断が、高負荷時におけるデータベースのパフォーマンスを支える大きな支柱になっているのです。
ロック待ちグラフの深淵
検出器が動き出すと、システムは現在ロックを保持しているトランザクションと、それを待っているトランザクションの関係性を「待ちグラフ（Wait-for Graph）」として構築します。
このアルゴリズムの肝は、再帰的な探索です。あるトランザクションが「Aのロックを欲しがっているが、そのAはBが持っている。BはCが待っているロックを欲しがっている……」といった依存関係の連鎖を辿ります。
この探索中に自分自身に戻ってくるパスが見つかれば、それは循環参照、すなわちデッドロックの確定です。この瞬間、検出器は非情にも、その連鎖に含まれるいずれかのトランザクションを `ERROR: deadlock detected` で強制終了させます。
現場で直面する「見えないデッドロック」への処方箋
実務でデッドロックに遭遇したとき、単にエラーコードを眺めるだけでは不十分です。トラブルシューティングの現場では、以下の視点が重要になります。
- ロックの順序を揃える:
これは基本中の基本ですが、アプリケーション層での実装漏れが非常に多い箇所です。異なるテーブル、あるいは同じテーブルの異なる行に対して、常に一定の順序（例：主キーの昇順）でロックを取得するようルール化するだけで、デッドロックの発生頻度は劇的に下がります。
- `deadlock_timeout` の安易な変更を避ける:
「デッドロックが起きるから」と、この値を短くするのは悪手です。誤検出や、短時間のロック競合を過剰に検知してパフォーマンスを悪化させるリスクがあります。むしろ、この時間が経過するほどロック待ちが常態化しているという「設計上の負債」に目を向けるべきです。
- `pg_locks` での可視化:
デッドロックが頻発する環境では、`pg_locks` ビューを定期的にサンプリングするスクリプトを走らせることをお勧めします。どのリソース（Relation, Tuple, Extensionなど）が競合の震源地になっているのかを特定できれば、インデックスの調整やロック粒度の見直しといった、根本的な解決策が見えてきます。
最後に：データベースと対話するということ
PostgreSQLのデッドロック検出器は、決して「エラーを出すためのもの」ではありません。それは、並行処理というカオスな世界で、データの整合性を守りつつ、システム全体の生存を維持するための「最後の防波堤」です。
私たちが書いたコードがこの検出器の手を煩わせていないか。そう自問自答しながらクエリを書き、トランザクションの範囲を設計する。そんな「データベースの作法」を大切にしているエンジニアこそが、真に高負荷なシステムを支配できるのだと、私は信じています。
次は、このロックの背後にある「MVCCと同時実行制御」のさらに深い領域について触れてみたいと思います。またお会いしましょう。
コメント