PostgreSQLのロックの仕組みについて、データベース内部実装（SpinlockやLWLockなど）のディープな世界を深掘りする2回エピソードの後編です。

今回は、DBAやデータベース開発者、並行プログラミングに関心がある方向けに、PostgreSQLの内部的な排他制御を解説します。CPUのアトミック命令であるCAS (Compare-and-Swap) を前提知識として、WAL (Write-Ahead Logging)の書き込みなどで使われ競合時にスリープする「Lightweight Lock (LWLock)」と、スリープせずにCPUを回し続けてロック獲得を待つ「Spinlock」の仕組みや用途の違いを整理します。

さらに、Linux 7.0環境で話題になったPostgreSQLの性能劣化問題の真相に迫ります。カーネルのスケジューラ変更（プリエンプションの挙動変化）がSpinlockに与えた影響や、PostgreSQLコミッタが指摘する、Spinlockをfutexに置き換えることの構造的な難しさを紹介します。また、この性能劣化報告の根本的な原因が「Huge Pages」の未設定によるTLBミスとページテーブル探索のオーバーヘッドにあったことを挙げ、OS・CPUレベルの適切なパラメータ設定がいかに重要であるかを議論します。

PostgreSQL内部実装 / CAS命令 (Compare-and-Swap) / Lightweight Lock (LWLock) / Spinlock / WAL書き込み / Linux 7.0性能劣化問題 / プリエンプション / futex / Huge Pages / パラメータチューニング

参考リンク

• ⁠PostgreSQLのロックでハマりがちな挙動5選⁠
• ⁠AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be Easy⁠
• ⁠I really dislike the use of spinlocks in postgres

PostgreSQLのロックの仕組みについて、アプリケーション開発者向けの視点から、データベース内部実装（SpinlockやLWLockなど）のディープな世界までを2回に分けて深掘りします。

前編となる今回は、アプリケーション開発者が気を付けるべき「はまりどころ」を解説します。複数トランザクションの同時更新や本番環境でのDDL（ALTER TABLEなど）実行時など、ロックの理解が不可欠なケースを取り上げ、4種類のテーブルロックと行ロック（FOR UPDATE）の基本を整理します。

さらに、実践的な5つのトラブルケースとその対策を紹介します。長時間のSELECTとALTER TABLEが引き起こす連鎖的なブロックや、外部キー・ユニーク制約の暗黙的ロックによるINSERT同士のデッドロックを解説します。また、例外的に自動キャンセルされない「トランザクションID周回防止バキューム」や、テーブルファイル末尾のページ切り詰め処理に潜む罠など、予期せぬサービス停止を防ぐための知識を議論します。

PostgreSQLのロック / MVCC / テーブルロックと行ロック / FOR UPDATE / Access Exclusive / デッドロック / ALTER TABLEの連鎖ブロック / 外部キー・ユニーク制約の暗黙的ロック / トランザクションID周回防止バキューム / ページ切り詰め

参考リンク

• PostgreSQLのロックでハマりがちな挙動5選
• AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be Easy
• I really dislike the use of spinlocks in postgres

Lonが「A Field Guide to Sandboxes for AI」というMistral AIのエンジニア Luisさんが書いたブログを紹介しながら、AIエージェントを安全に実行するためのサンドボックス環境について勉強した内容を共有しています。サンドボックスを正しく理解するための3つの軸（Boundary、Policy、Lifecycle）と、4種類のBoundary（コンテナ、gVisor、microVM、Wasm）の違いを学びます。また、Claude CodeやCodexが採用しているSeatbelt（Mac）やBubblewrap（Linux）についても紹介しています。

配信プラットフォーム追加のお知らせ / サンドボックスとは何か / Boundaryの4種類 / コンテナの仕組み（namespaces、capabilities、cgroups、seccomp） / gVisorとSentry / microVMとゲストカーネル / WebAssembly / Policyの重要性 / Lifecycle / Claude CodeのサンドボックスとSeatbelt・Bubblewrap / Credentialの安全な扱い方 / Proxyパターン

補足・訂正

• Wasm の説明で「ランタイムで定義されたシステムコールだけがホストカーネルを呼ぶ」と表現しましたが、正確には Wasm モジュール自体は system call を行えず、WASI (WebAssembly System Interface) API を介してランタイムが host system call に翻訳する形になります。

参考リンク

• A Field Guide to Sandboxes for AI: https://www.luiscardoso.dev/blog/sandboxes-for-ai

• Claude Code Sandboxing: https://code.claude.com/docs/en/sandboxing

• Securely Deploying AI Agents (Claude Code): https://code.claude.com/docs/en/agent-sdk/secure-deployment#containers

• WebAssembly System Interface (WASI): https://wasi.dev/