PostgreSQL ロック機構の内部構造を徹底解説：行ロック、Advisory Lock、SSI まで

はじめに

この記事では、PostgreSQLのロック機構の内部実装を深掘りします。

前回の記事（InnoDB ロック機構の内部構造を徹底解説）ではMySQLのロックを解説しました。PostgreSQLはInnoDBと異なり、Gap Lockがありません。代わりにSSI（Serializable Snapshot Isolation）という独自のアプローチでファントムリードを防ぎます。PostgreSQL 17を中心に解説します。

ロックの階層

PostgreSQLのロックは3つのレイヤーに分かれます：

ユーザーが意識するのは主にRegular Lockです。

テーブルレベルロック

PostgreSQLは8種類のテーブルロックモードを持ちます（InnoDBは実質IS/IX/S/Xの4種類）。

-- 明示的なテーブルロック
LOCK TABLE employees IN SHARE MODE;

-- 現在のロック確認
SELECT * FROM pg_locks WHERE relation = 'employees'::regclass;

InnoDBとの違い：PostgreSQLはDDL操作ごとに細かくロックモードが分かれています。例えばCREATE INDEX CONCURRENTLYはSHARE UPDATE EXCLUSIVEという弱いロックで、DMLをブロックしません。

行レベルロック

InnoDBとの根本的な違い

InnoDBの行ロックはインデックスレコードにかかります。PostgreSQLの行ロックはタプル（行）自体にかかります。

InnoDB:    インデックスのレコードにロック → Gap Lock、Next-Key Lockが可能
PostgreSQL: Heapのタプルにロック → Gap Lockの概念がない

4種類の行ロック

InnoDBにはないFOR NO KEY UPDATEとFOR KEY SHAREがあります。これにより、外部キー制約のチェックと通常のUPDATEが互いにブロックしにくくなっています。

行ロックの実装：タプルヘッダ内

PostgreSQLの行ロックはタプルヘッダのxmaxを利用します。ロック専用の領域を持たず、MVCCの仕組みを再利用しています。

タプルヘッダ:
  xmax = ロックを保持するTxID
  t_infomask: HEAP_XMAX_LOCK_ONLY フラグ（削除ではなくロックであることを示す）

InnoDBが別途ロックテーブル（lock_sys）を持つのに対し、PostgreSQLはタプル自体にロック情報を埋め込むのが特徴です。

Gap Lockがない：ファントムリードはどう防ぐ？

InnoDBはGap Lock / Next-Key Lockでファントムリードを防ぎます。PostgreSQLにはGap Lockがありません。

REPEATABLE READレベル

PostgreSQLのREPEATABLE READはMVCC（Snapshot）だけで実現します。Snapshot取得時点のデータしか見えないため、ファントムリードはそもそも発生しません。

Tx A (REPEATABLE READ):
  SELECT * FROM t WHERE id BETWEEN 3 AND 7;  → 結果: {5}
  
Tx B: INSERT INTO t VALUES (4); COMMIT;

Tx A:
  SELECT * FROM t WHERE id BETWEEN 3 AND 7;  → 結果: {5}（Snapshotが同じ）

ただし、これは「見えない」だけで「防いでいる」わけではありません。Write Skew異常は発生し得ます。

SERIALIZABLEレベル：SSI

PostgreSQLのSERIALIZABLEはSSI（Serializable Snapshot Isolation）で実装されています。ロックではなく、依存関係の検出で直列化可能性を保証します。

SSIの仕組み:
  1. 各トランザクションの読み取り/書き込みの依存関係を追跡
  2. 直列化不可能な依存パターン（dangerous structure）を検出
  3. 検出したらトランザクションをアボート

InnoDBのSERIALIZABLE:
  1. 全SELECTがSELECT ... FOR SHARE相当
  2. ロックで直列化を強制

Advisory Lock

PostgreSQL固有の機能で、アプリケーション定義のロックです。

-- セッションレベルのAdvisory Lock
SELECT pg_advisory_lock(12345);      -- 取得
SELECT pg_advisory_unlock(12345);    -- 解放

-- トランザクションレベル
SELECT pg_advisory_xact_lock(12345); -- トランザクション終了時に自動解放

-- 非ブロッキング（取得できなければfalseを返す）
SELECT pg_try_advisory_lock(12345);

用途： – 外部リソースの排他制御（ファイル、API等） – アプリケーションレベルのキューイング – 重複処理の防止

InnoDBにはGET_LOCK()関数がありますが、PostgreSQLのAdvisory Lockの方が高機能です（共有/排他、セッション/トランザクションレベルの選択が可能）。

デッドロック検出

PostgreSQLもInnoDBと同じくWait-for Graphでデッドロックを検出します。

-- デッドロック検出の待機時間（デフォルト1秒）
SET deadlock_timeout = '1s';

InnoDBが即座に検出するのに対し、PostgreSQLはdeadlock_timeoutの間待ってから検出を開始します。多くの場合、タイムアウト前にロックが解放されるため、検出コストを節約できます。

まとめ

次回はOracle ロック機構を解説します。

参考文献

• PostgreSQL Documentation: Explicit Locking
• PostgreSQL Documentation: SSI
• PostgreSQL Documentation: Advisory Locks
• PostgreSQL Wiki: SSI