【PostgreSQL】デッドロックの原因と対策をわかりやすく解説

スポンサーリンク

PostgreSQLでは、データの一貫性を保つために様々なロックが使用されていますが、その中で特に注意が必要なのが「デッドロック（Dead Lock）」です。

デッドロックとは、複数のトランザクションが互いに相手のロック解除を待ち続ける状態のことです。この状態が発生すると、どちらの処理も進まなくなり、データベースのパフォーマンスに悪影響を及ぼします。幸い、PostgreSQLにはデッドロックを検出して自動的に解決する仕組みがありますが、頻発するとシステムの安定性が損なわれるため、適切な対策が必要です。

本記事では、PostgreSQLにおけるデッドロックの仕組みと発生原因を解説し、実践的な回避策を紹介します。デッドロックを正しく理解し、適切に対処することで、スムーズなデータベース運用を実現しましょう。

デッドロックの基本

デッドロックは、複数のトランザクションが互いにロックを取得し、相手のロックが解除されるのを待ち続けることで発生します。この状態では、どちらのトランザクションも進行できず、システムが停止したような状態になります。PostgreSQLでは、一定時間デッドロック状態が続くと、自動的に一方のトランザクションを強制終了して処理を進める仕組みが備わっています。

PostgreSQLにおけるロックの種類

PostgreSQLでは、データの整合性を保つためにさまざまなロックが提供されています。代表的なものを以下に示します。

  • 行ロック（Row-Level Lock）
    特定の行に対して適用されるロックで、一般的な SELECT ... FOR UPDATE や UPDATE 文で使用されます。
  • テーブルロック（Table-Level Lock）
    テーブル全体に対して適用されるロックで、LOCK TABLE 文や ALTER TABLE などの操作時に発生します。
  • 排他ロック（Exclusive Lock）
    あるトランザクションが特定のリソースに対して排他的なアクセスを取得し、他のトランザクションがアクセスできないようにするロックです。

デッドロックが発生する条件

デッドロックは、以下のような条件がそろったときに発生します。

  1. 複数のトランザクションが同じリソースにアクセスしようとする
    例：トランザクションAがテーブルXの行をロックし、トランザクションBがテーブルYの行をロックする。
  2. トランザクションが異なる順序でロックを取得しようとする
    例：トランザクションAがテーブルXをロックした後、テーブルYをロックしようとする。一方で、トランザクションBがテーブルYをロックした後、テーブルXをロックしようとする。
  3. お互いのロック解除を待ち続ける
    どちらのトランザクションも相手のロックが解除されるまで待機するため、処理が進まなくなる。

このような状況になると、PostgreSQLは deadlock_timeout（デフォルトは1秒）を超えた時点でデッドロックを検出し、一方のトランザクションを強制的に終了させて解決します。しかし、デッドロックが頻発するとシステムのパフォーマンスに悪影響を与えるため、回避策を講じることが重要です。

デッドロックの発生原因

デッドロックは、複数のトランザクションが互いにロックを取得し、相手のロック解除を待ち続けることで発生します。特に以下のようなケースでデッドロックが起こりやすくなります。

トランザクション間のロック競合

同じデータに対して、複数のトランザクションが異なるロックを取得しようとすることで競合が発生します。

-- セッションA
BEGIN;
UPDATE products SET price = price * 1.1 WHERE id = 1;

-- セッションB
BEGIN;
UPDATE products SET price = price * 0.9 WHERE id = 2;

-- セッションA
UPDATE products SET price = price * 1.1 WHERE id = 2; -- ここでセッションBのロック待ち

-- セッションB
UPDATE products SET price = price * 0.9 WHERE id = 1; -- ここでセッションAのロック待ち（デッドロック発生）

このように、セッションAとセッションBが互いに相手のロックを解除するのを待ってしまい、デッドロック状態になります。

ロック取得の順序の違い

トランザクションが異なる順序で同じテーブルや行のロックを取得しようとすると、デッドロックが発生することがあります。

  • セッションA：テーブルX → テーブルY の順でロックを取得
  • セッションB：テーブルY → テーブルX の順でロックを取得

この場合、両方のセッションが相手のロック解除を待ち続けるため、デッドロックに陥ります。

長時間のトランザクション

1つのトランザクションが長時間ロックを保持していると、他のトランザクションがロック待ちの状態になり、デッドロックのリスクが高まります。特に、大量のデータを処理する場合や、外部システムとの連携で待機が発生するケースでは注意が必要です。

外部キー制約やインデックスの影響

PostgreSQLでは、外部キー制約を持つテーブル間で DELETE や UPDATE を実行すると、自動的に関連する行にロックがかかることがあります。この結果、意図しないデッドロックが発生することがあります。

-- 親テーブルから削除
DELETE FROM parent_table WHERE id = 1;

-- 子テーブルで該当するレコードを削除
DELETE FROM child_table WHERE parent_id = 1;

このように、削除の順序や外部キー制約の影響によってデッドロックが発生することがあります。

アップデートの競合

同じ行に対して複数のトランザクションが同時に UPDATE を実行すると、ロック競合が発生し、デッドロックの原因になります。特に、UPDATE 文が複数のテーブルをまたぐ場合、デッドロックの可能性が高まります。

デッドロックの確認方法

デッドロックが発生すると、トランザクションが進行しなくなり、最終的にPostgreSQLが一方のトランザクションを強制終了してエラーを発生させます。デッドロックの発生を防ぐためには、事前にロックの状態を確認し、適切に管理することが重要です。ここでは、PostgreSQLでデッドロックを確認するための方法を紹介します。

pg_stat_activity を使ったセッションの確認

デッドロックの可能性がある場合、まず pg_stat_activity を使って現在のセッションの状態を確認しましょう。

SELECT pid, usename, state, wait_event, query, query_start 
FROM pg_stat_activity 
WHERE state != 'idle' 
ORDER BY query_start;
  • pid: プロセスID
  • usename: 実行ユーザー
  • state: 実行状態（active や idle in transaction など）
  • wait_event: ロック待ちの状態を示す（Lock になっている場合はロック待ちの可能性あり）
  • query: 実行中のSQL文
  • query_start: クエリの開始時刻

この情報をもとに、長時間実行されているトランザクションやロック待ちのトランザクションを特定できます。

pg_locks を使ったロック状況の監視

現在発生しているロックの状態を確認するには、pg_locks ビューを利用します。

SELECT pid, locktype, relation::regclass, mode, granted 
FROM pg_locks 
WHERE NOT granted;
  • pid: ロックを取得しようとしているプロセスID
  • locktype: ロックの種類（relation や tuple など）
  • relation: ロックされているテーブルやインデックスの名前
  • mode: ロックのモード（RowExclusiveLock など）
  • granted: ロックが付与されているかどうか（false の場合はロック待ち状態）

granted = false のレコードが多数ある場合、ロック競合が発生している可能性が高いです。

deadlock_timeout の設定によるデッドロックのログ出力

PostgreSQLでは、デッドロックが発生すると一定時間（deadlock_timeout）待機した後、自動的にデッドロックを検出し、関連する情報をログに記録します。

デフォルトでは deadlock_timeout は 1秒（1000ミリ秒） に設定されていますが、短縮することでデッドロックの発生を素早く検知できます。

設定の確認

SHOW deadlock_timeout;

値を変更する場合（例：500ミリ秒に設定）

ALTER SYSTEM SET deadlock_timeout = '500ms';
SELECT pg_reload_conf(); -- 設定を反映

デッドロックが発生した場合、PostgreSQLのログに以下のようなメッセージが記録されます。

ERROR:  deadlock detected
DETAIL:  Process 1234 waits for ShareLock on transaction 5678; blocked by process 5678.

このメッセージを確認することで、どのプロセスがデッドロックの原因になっているかを特定できます。

デッドロック発生時のセッションの強制終了

デッドロックを解消するために、影響を受けているセッションを手動で強制終了することもできます。

デッドロック状態にあるプロセスを特定

SELECT pid, usename, query 
FROM pg_stat_activity 
WHERE wait_event = 'Lock';

特定のセッションを終了

SELECT pg_terminate_backend(<pid>);

※ pg_terminate_backend を使用する際は、影響範囲をよく確認してから実行してください。

デッドロックの回避策

デッドロックはPostgreSQLが自動的に検出し、一方のトランザクションを強制終了することで解決されます。しかし、頻発するとパフォーマンスの低下や処理の失敗につながるため、事前に適切な対策を講じることが重要です。ここでは、デッドロックを回避するための実践的な方法を紹介します。

トランザクションのロック取得順序を統一する

デッドロックの主な原因は、トランザクションが異なる順序でロックを取得しようとすることです。そのため、すべての処理でロックを取得する順序を統一すると、デッドロックを回避しやすくなります。

トランザクションを短くする

長時間のトランザクションは、他のプロセスをブロックし、デッドロックを引き起こす可能性を高めます。可能な限り、トランザクションの実行時間を短くするようにしましょう。

対策：

  • SELECT 文の後に不要な BEGIN; を使用しない。
  • 必要なデータを取得したらすぐに COMMIT; する。
  • 大量のデータ更新が必要な場合は、小さなバッチに分ける。

NOWAIT や SKIP LOCKED を活用する

デッドロックを防ぐために、ロック待ちを発生させない方法として NOWAIT や SKIP LOCKED を使用することができます。

  • NOWAIT：ロックされている行がある場合、即座にエラーを返す。
  • SKIP LOCKED：ロックされている行をスキップし、取得可能なデータのみを取得する。
-- `NOWAIT` を使用（ロックされている場合はエラー）
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE NOWAIT;

-- `SKIP LOCKED` を使用（ロックされている行を除外）
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE SKIP LOCKED;

これにより、ロック待ちが発生せず、デッドロックのリスクを低減できます。

まとめ

デッドロックは、複数のトランザクションが互いにロックを待ち続けることで発生する問題です。PostgreSQLではデッドロックを自動検出して対処しますが、頻繁に発生するとパフォーマンスの低下や処理の失敗につながるため、適切な回避策を講じることが重要です。

本記事では、デッドロックの発生原因とその確認方法、そして回避策について解説しました。

これらの対策を実施することで、デッドロックの発生を抑え、安定したPostgreSQLの運用が可能になります。デッドロックの発生が疑われる場合は、まず pg_stat_activity や pg_locks を活用して状況を把握し、適切な回避策を検討しましょう。

スポンサーリンク

コメント

タイトルとURLをコピーしました