ライトスキュー とは？

スナップショット分離で起きる異常の1つだよ。2つのトランザクションが同じデータを読んで「これなら大丈夫」と判断し、それぞれ別の行を更新した結果、全体のルールが破れてしまうんだ。

病院の当直医の例が有名だよ。「当直は常に1人以上」というルールがあって、AliceとBobが当直中とするね。2人が同時に「もう1人いるから休んでも大丈夫」と確認して、それぞれ自分の行を「休み」に更新すると、当直が0人になってしまうんだ。

スナップショット分離では、異なる行への更新だけなら直接の書き込み競合にならないことがあるよ。各自が見ているスナップショットに相手の更新が反映されず、読み取った集合に基づく判断が食い違うんだ。PostgreSQLのREPEATABLE READでは、最初の通常の文を実行した時点の状態を基準にするよ。

SERIALIZABLEで直列実行と同じ結果を保つ方法があるよ。PostgreSQLでは危険な読み書きの影響関係を検出し、必要ならトランザクションを失敗させる。アプリ側は失敗したSQLだけでなく、トランザクション全体を最初から再試行する。ルールを正しくチェックする処理と、競合する処理の分離レベルをそろえる設計も必要だよ。

当直医の例なら、判断に使う行を更新前にロックする方法があるよ。ただし競合するすべての処理が同じロック規則を守り、必要に応じて再試行する設計が必要なんだ。条件によってはUNIQUE制約や時間範囲の排他制約で競合をDBに調停させられる。普通のCHECK制約や、トリガー内で件数をSELECTするだけでは、複数行にまたがる条件を同時更新から守れるとは限らないよ。該当行が存在しないことを調べる場合も、既存行をロックするだけでは足りないんだ。