SQL 第 3 弾: トランザクションとロックで「壊れない送金処理」を作る

このラボでは、社内のポイント送金機能を任されたバックエンド担当の想定で、「残高が消える」「二重に送られる」「マイナスになる」を DB の仕組みで防ぐ方法を実機で身につけます。

ブラウザで開く IDE の PostgreSQL に、口座テーブル accounts（10 口座 × 100,000 円、合計 1,000,000 円）が入っています。送金関数を PL/pgSQL で書き、わざと失敗させて「途中で止まっても残高の合計は変わらない」ことを確かめ、2 つのターミナルで同じ口座を同時に更新してロック待ちを観察します。

学習目標:

• BEGIN / COMMIT / ROLLBACK と、関数内の例外による自動ロールバック（原子性）
• SELECT ... FOR UPDATE による行ロックで、同時更新の競合を防ぐ
• CHECK 制約で「残高は 0 以上」を DB 側で保証する
• トリガーで更新履歴（監査ログ）を自動で残す
• pg_locks / pg_stat_activity でロック待ちを観察する

• UPDATE / SELECT の基本と、「SQL 入門」「SQL 中級」ラボ相当の知識

• balance >= 0 の CHECK 制約、transfer(from_id, to_id, amount) 関数（FOR UPDATE を使用）、transfer_audit への記録トリガーがあること
• 3,000 円の送金で残高が 97,000 / 103,000 になり合計が 1,000,000 のままで、残高不足の送金はエラーで何も変わらないこと
• locks_notes.md にロック待ちの観察結果が書かれていること

1. ブラウザ IDE を開いて口座テーブルを確認する

• ラボ画面の ブラウザ IDE を開く をクリックし、表示されているパスワードでサインインする
• README.md を読み、Terminal → New Terminal でターミナルを開いて PostgreSQL に接続する

psql "$DATABASE_URL"

SELECT * FROM accounts ORDER BY id;
SELECT sum(balance) FROM accounts;   -- 1000000

> 注: このラボでは「合計 1,000,000 円が常に保たれるか」を正しさの目安にします。送金は片方を減らしてもう片方を増やすだけなので、合計は決して変わらないはずです。

• PostgreSQL 日本語ドキュメント: トランザクション
• PostgreSQL: 明示的ロック（FOR UPDATE）
• PostgreSQL: PL/pgSQL の制御構造とエラー
• PostgreSQL: トリガ関数