PostgreSQLのロック機構はどのように動作しますか?

Question

Accepted Answer

PostgreSQLは**ロック**を使用して同時実行アクセスを調整し、競合を防止します。**MVCC**のおかげで、読み取りは一般的にロックを必要としません(読み取り側はライター側をブロックしない)が、書き込みは行レベルのロックを取得し、様々なロック型が操作を調整します。ロック機構を理解することで、競合とデッドロックを回避できます。

## MVCCは読み取りは通常ロックが不要

```text
Because of MVCC, plain SELECTs do NOT take row locks — they read a consistent snapshot.
→ Readers don't block writers, writers don't block readers (a key Postgres advantage).
Locking mainly comes into play for WRITES and explicit locking.
```

## 行レベルロック(書き込みと明示的なロックから)

```sql
-- UPDATE/DELETE automatically lock the affected ROWS (until the transaction ends)
UPDATE accounts SET balance = balance - 100 WHERE id = 1;   -- locks row 1

-- SELECT ... FOR UPDATE — explicitly lock rows you intend to update (prevent races)
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;   -- lock the row
-- ... compute, then UPDATE — no other transaction can modify it meanwhile
UPDATE accounts SET balance = ... WHERE id = 1;
COMMIT;
```

`SELECT ... FOR UPDATE`は行をロックし、並行トランザクションがそれらを変更できないようにします — 読み取り・変更・書き込み操作の競合状態を防止します(例えば、安全に在庫を減らす場合)。

## ロック型とテーブルロック

```text
ROW-level → ACCESS via UPDATE/DELETE/SELECT FOR UPDATE — fine-grained
TABLE-level → some DDL (ALTER TABLE) takes heavier table locks → can block queries
→ Schema changes on busy tables can cause contention; plan migrations carefully
  (Postgres has gotten better — many ALTERs are now non-blocking, but not all).
```

## ロック問題とデッドロックを回避する

```text
✓ Keep transactions SHORT (hold locks briefly → less contention)
✓ Acquire locks in a CONSISTENT ORDER across transactions → avoid DEADLOCKS
✓ Use FOR UPDATE deliberately for read-modify-write; consider FOR UPDATE SKIP LOCKED
  for queue-like patterns (skip already-locked rows)
✓ Watch for long-held locks blocking others (pg_locks, pg_stat_activity to diagnose)
✓ Be cautious with DDL on busy tables (can block)
```

## なぜ重要なのか

PostgresQLのロック機構を理解することは、**正確で高性能な並行アプリケーションの構築**に重要であり、重大な並行データベースアクセスを持つシステムにおけるシニアレベルの知識として価値があります。

基本的な洞察は、**MVCCは読み取りは通常ロックが不要**ということです(読み取り側はライター側をブロックしません — PostgreSQLの重要な並行実行の利点)。そのため、ロックは主に**書き込みと明示的なロック**に関心があります。

**行レベルロック**(UPDATE/DELETEによって取得される)を理解し、特に**`SELECT ... FOR UPDATE`**(読み取り・変更・書き込み操作の競合状態を防ぐために明示的に行をロックする — 在庫を安全に減らしたり、残高を処理したりする場合、ロックなしでは並行トランザクションが不正な結果を引き起こす可能性がある)を理解することは、**正確性**のために並行シナリオで重要です。

**DDL/スキーマ変更はより重いテーブルロックを取得できる**こと(混在したテーブル上のクエリをポテンシャル的にブロック — マイグレーション計画時の重要な考慮事項。ただし、Postgresは多くのALTERを非ブロッキングに改善しています)は、デプロイ中の競合を回避するのに役立ちます。

**ロック問題とデッドロックを回避する方法**を理解すること — トランザクションを短く保つ(短時間ロックを保持)、ロックを一貫した順序で取得する(デッドロックを防止)、`FOR UPDATE`を意図的に使用する(キューパターンには`SKIP LOCKED`を使用)、ロック競合を診断する(pg_locks、pg_stat_activity) — は並行性の下での性能と信頼性にとって価値があります。

並行実行は実際のアプリケーションに固有のものであり、適切なロック使用(特に読み取り・変更・書き込み操作の正確性のための`FOR UPDATE`、および競合/デッドロックの回避)が並行データベースコードを正確で高性能にするので、PostgreSQLのロック機構を理解すること — MVCCの読み取りロックなしモデル、正確性のための明示的な行ロック、DDLからのテーブルロック、デッドロック/競合の回避 — は堅牢な並行アプリケーションを構築し、負荷の下でPostgresを運用するためのシニアレベルの知識であり、頻繁に関連する関心事であり、データベース並行実行制御の理解を実証しています。