TOCTOUとは？排他制御とトランザクションの違いを検証

そもそも「トランザクションでよくない？」と思った理由#

例えば、在庫が10個あるとする。

処理Aと処理Bが同時に、

1. 在庫を取得する（10個）
2. 1個減らす計算をする（9個）
3. DBを更新する

という処理を行うケース。

最初は「両方をトランザクション（BEGIN 〜 COMMIT）にすれば、DB側でうまく調整してくれるでしょ」と思ってた。

で、実際にこんな感じのSQLを試してみた。

BEGIN;

SELECT stock FROM products WHERE id = 1;

UPDATE products
SET stock = 9
WHERE id = 1;

COMMIT;

処理Aと処理Bの両方が在庫10を読み取って、そのあとに「9」を書き込む流れ。

期待としては2回減って「8」になってほしいところだけど、結果は最終的な在庫が「9」になってしまった。

【実測結果】#

PostgreSQL 18.6で試した結果がこれ：

• Aが在庫10を取得
• Bも在庫10を取得
• Aが9を書き込む
• Bが待機状態になる
• AがCOMMITする
• Bが待機解除されて9を書き込む
• 最終値が9になる（本来は8になってほしい）

ここで分かったのは、

トランザクションは「人間の処理の意図」まで勝手に汲み取って合成してくれるわけじゃない

ということ。

ちなみに、

UPDATE products
SET stock = stock - 1
WHERE id = 1;

みたいにDB上で直接引き算（相対更新）をする書き方なら、同時実行しても順番に適用されて在庫はちゃんと「8」になった。

つまり、同じ「在庫を1減らす」処理でも、アプリ側で値を読み込んで固定値を書き戻すのか、DB上で引き算するのかで結果がガラッと変わる。

【実測結果】#

処理Aが最初に確認した時点では在庫10だった。

でも、処理Aが更新する前に処理Bが在庫を0に変えてしまっている。

それなのに処理Aは「さっき在庫10だったからOK！」という古い前提のまま更新をかけちゃったわけ。

これがTOCTOUの基本的な構造。

sequenceDiagram
    autonumber
    participant A as 処理A
    participant DB as PostgreSQL
    participant B as 処理B (割り込み)

    A->>DB: 【Check】SELECT (在庫10を確認)
    Note over A: 「在庫10あるからOK」と判定
    B->>DB: UPDATE (在庫を0に変更＆COMMIT)
    Note over DB: 在庫が 0 に変動！
    A->>DB: 【Use】UPDATE (在庫を9に変更)
    Note over DB: 在庫0なのに「さっき10だった」前提で9に上書き

ポイントなのは、TOCTOU自体は「排他制御の手法」を指す言葉じゃないということ。

「Check」と「Use」の間に状態が変わってしまい、古い確認結果のまま処理を進めてしまう現象そのものがTOCTOUってわけ。

【実測結果】#

処理BのUPDATEはすぐには終わらず、処理AがCOMMITするまでしっかり待たされた。

動きとしてはこんなイメージ：

sequenceDiagram
    autonumber
    participant A as 処理A
    participant DB as PostgreSQL
    participant B as 処理B

    A->>DB: BEGIN
    A->>DB: SELECT ... FOR UPDATE
    Note over DB: id=1 の行をロック取得！
    B->>DB: BEGIN
    B->>DB: UPDATE (id=1)
    Note over B,DB: 処理Aがロック中のため待機...
    A->>DB: UPDATE (stock = 9)
    A->>DB: COMMIT
    Note over DB: ロック解除！
    B->>DB: 待機解除 → UPDATE 実行 & COMMIT

ただ、ここで一つ「おや？」と思う結果に。

処理Aがロック中に在庫を9に変更してCOMMITしたあと、待たされていた処理BのUPDATEが実行されて、結局Bの更新内容が最終値になった。

PostgreSQLの仕様的にも、SELECT FOR UPDATE は他のトランザクションによる更新を「一時的にブロック」するけど、ロックが解除されたあとは待機していた処理がそのまま続行される。

つまり、

FOR UPDATE は「自分だけが永久に勝つための魔法」ではない

ということ。

チェックから利用までの間に他人が割り込んでくるのを防ぐためのガード、と考えると納得がいった。

【実測結果】#

実際に試すと、処理AのUPDATE結果は UPDATE 0 になり、在庫0を「9」で上書きしてしまう事故を防げた。

UPDATE 0 はSQLのエラーではなく、「条件に合う行がなかったから0件更新したよ」という正常なレスポンス。

でも、

AND stock = 10

みたいに実際のデータ値を直接条件にすると、値が元に戻った時（10 → 5 → 10みたいなケース）に誤検知するリスクがあって扱いづらいこともある。

そこでよく使われるのが**バージョン番号（version）**を入れる手法。

テーブルに version カラムを用意しておく：

id | stock | version
---+-------+--------
 1 |  10   |    1

処理Aが version = 1 を読み取ったあと、処理Bが先に更新すると：

id | stock | version
---+-------+--------
 1 |   0   |    2

になる。

そのあと処理Aが、

UPDATE products
SET stock = 9,
    version = version + 1
WHERE id = 1
  AND version = 1; -- さっき取得したversion=1を条件にする

を実行しても、今のversionは2になっているので更新条件にマッチせず、UPDATE 0 になる。

これが**楽観的排他（楽観的ロック）**の考え方。

最初に行をロックして相手を待たせるのではなく、

更新する時に「自分が読み取った状態から変わっていないか？」をチェックして、変わっていたら失敗（競合）とする

というアプローチ。

検証環境#

• OS：Windows 11
• DB：PostgreSQL 18.6（ZIP版を手動起動）
• クライアント：psql（セッション2つ）

バージョン方式の同時更新テスト#

処理Aと処理Bの両方で、

SELECT stock, version
FROM products
WHERE id = 1;

を実行して、どちらも stock = 10, version = 1 を取得。

次に処理Aが、

UPDATE products
SET stock = stock - 1,
    version = version + 1
WHERE id = 1
  AND version = 1;

を実行。処理Aは無事に UPDATE 1 になった。

続けて処理Bがまったく同じUPDATEを実行すると、一瞬待機したあとに UPDATE 0 となった。

最終的なデータを確認すると：

stock   = 9
version = 2

【実測結果】#

2つの処理が同時に version = 1 を読み取っていても、更新に成功するのは最初にコミットした1つだけ。

これによって、古い状態を元にした更新が勝手に上書きされるのを防げる。

【実測結果】#

実際に試したら、こんなエラーが出た：

ERROR: デッドロックを検出しました

psqlのプロンプトもエラー状態を示す postgres=!# に変わった。

この後、

ROLLBACK;

を実行して元のプロンプト（postgres=#）に復帰。

データを確認すると：

id | name  | stock | version
---+-------+-------+--------
 1 | 商品A |     9 |       2
 2 | 商品B |    10 |       1

片方の処理だけが適用されていた。

公式ドキュメントの対策#

PostgreSQLの公式ドキュメントによると、デッドロックを防ぐ基本は**「複数の行をロックするときは、どの処理でも必ず同じ順番でロックを取得すること」**。

それでも防げない場合は、エラーが起きた時にトランザクション全体をリトライ（再試行）する設計にしておく必要がある。