博士

やあ、ロボ子。今日はデータベースのデッドロックについて話すのじゃ。

ロボ子

デッドロックですか、博士。複数のトランザクションが互いにロックを待って動けなくなる状態ですよね。なんだか難しそうです。

博士

そう、まさにそれなのじゃ。しかも、デッドロックの原因特定はなかなか骨が折れるのじゃ。エラーメッセージが不親切だったり、トランザクション内のSQL文を全部把握する必要があったりするからの。

ロボ子

記事では`parent`テーブルと`child`テーブルを使った例が紹介されていましたね。2つのセッションがそれぞれ`child`テーブルにデータを挿入した後、`parent`テーブルを`FOR UPDATE`で更新しようとしてデッドロックが発生する、と。

博士

その通り！`FOR UPDATE`はロックを取得して更新する時に使うのじゃが、これが原因で競合が起きやすいのじゃ。

ロボ子

デバッグ方法もいくつか紹介されていましたね。アプリケーション側のロギング、クエリのアノテーション、データベース側のロギングなど…。

博士

そうじゃな。アプリケーション側のロギングは、エラーやトランザクション開始時に情報を記録する方法じゃ。でも、アプリケーションコードを修正する必要があるのが難点じゃな。

ロボ子

クエリのアノテーションは、クエリにコメントを追加してトランザクションを特定しやすくする方法ですね。これもコード修正が必要ですね。

博士

データベース側のロギングは、`log_line_prefix`を設定してプロセスIDとトランザクションIDをログに記録する方法じゃ。`log_statement = 'all'`で全てのSQL文をログに記録できるぞ。

ロボ子

`log_transaction_sample_rate`を使うと、特定の割合のトランザクションだけをログ記録できるんですね。でも、デッドロックに関わるトランザクションを全部捕捉できるとは限らない、と。

博士

その通りじゃ。あと、`deadlock_timeout`を増やすのも有効じゃ。デッドロック検出までの待機時間を長くして、その間に`pg_stat_activity`から情報を集めるのじゃ。

ロボ子

`client_addr`と`client_port`からクライアントマシンを特定して、該当プロセスを調べるんですね。

博士

そうじゃ。そして、デッドロック解決のヒントとして、`SELECT ... FOR UPDATE`を`SELECT ... FOR NO KEY UPDATE`に変更する方法もあるのじゃ。

ロボ子

`FOR NO KEY UPDATE`は、ロック競合を回避できる場合があるんですね。`FOR UPDATE`は、行を削除したり、主キーやユニークキー制約のあるカラムを更新する場合にのみ必要、と。

博士

そういうことじゃ！デッドロックのデバッグは、アプリケーションコードの制御が重要じゃが、全ての手法が全てのケースで有効とは限らないから、状況に応じて使い分ける必要があるのじゃ。

ロボ子

奥が深いですね、博士。勉強になりました！

博士

最後にロボ子、デッドロックはまるで、お互いがお互いのポテトチップスを欲しがって、誰も食べられない状態みたいなものじゃな！

ロボ子

それ、ただの食い意地が張ってるだけじゃないですか？