【実務・中級編】ラッチ (Latch) – PostgreSQL

PostgreSQLの「ラッチ（Latch）」：プロセスを賢く休ませる、舞台裏の指揮者

やあ。PostgreSQLのパフォーマンスチューニングや、内部構造の深掘りに興味があるんだね。いい趣味だ。

普段、PostgreSQLを使っていると「ロック（Lock）」や「軽量ロック（LWLock）」の話はよく耳にするだろう？でも、それらよりもさらに深い、OSレベルでのプロセス制御の要である「ラッチ（Latch）」について意識したことはあるかな？

今日は、PostgreSQLがなぜこれほどまでに多くのプロセスを効率よく捌けるのか、その秘密の一つである「ラッチ」について、現場の視点から紐解いていこうと思う。

—

ラッチって、結局なんなの？

一言で言えば、ラッチは「プロセスを賢くスリープさせ、必要な時に確実に起こすためのシグナリング機構」だ。

PostgreSQLはマルチプロセスアーキテクチャだ。クライアントごとにバックエンドプロセスが立ち上がるし、チェックポインターやウォッチャーのようなバックグラウンドプロセスも常に動いている。これらが常に「今か今か」とCPUをブン回してタスクをポーリング（監視）していたら、CPUなんて一瞬で枯渇してしまうよね。

そこで登場するのがラッチだ。

プロセスは「やるべき仕事がない」あるいは「誰かの作業待ち」になったとき、ラッチを使ってOSに「用事があるまで寝かせてくれ」と依頼する。そして、他のプロセスがその作業を終えて「終わったぞ！」という合図（ラッチのセット）を送ると、OSがスリープ中のプロセスを叩き起こす。

この仕組みがあるおかげで、PostgreSQLは非常に高い並列性と省電力性能を両立できているわけだ。

—

現場で見るラッチの姿：WaitEvent

皆さんが `pg_stat_activity` を覗いたとき、`wait_event_type` が `Latch` になっているのを見たことはないかな？

SELECT pid, wait_event_type, wait_event
FROM pg_stat_activity
WHERE wait_event_type = ‘Latch’;

これが出ているとき、そのプロセスは「何かを待っている状態」だ。もし、特定のプロセスが常に `Latch` 待ちで、かつ性能が出ないなら、それは「何か外部からのイベントやタスクの完了をずっと待っている」ということになる。

例えば、`ClientRead` や `ClientWrite` という待ちイベントは、実はラッチを介して「クライアントからデータが来るのを待っている」状態を指しているんだ。

—

コードで見る：ラッチの作法

PostgreSQLのソースコードを触る機会があるなら、必ずと言っていいほど出会うのが `WaitLatch` と `SetLatch` だ。

/ プロセス側の待機ロジックのイメージ /
while (condition_is_false)
{
/ ラッチを待機する。タイムアウト付きで安全に /
int rc = WaitLatch(MyLatch,
WL_LATCH_SET | WL_POSTMASTER_DIED | WL_TIMEOUT,
timeout_ms,
WAIT_EVENT_SOME_TASK);

if (rc & WL_POSTMASTER_DIED)
exit(1); / 親が死んだら自分も死ぬ /

if (rc & WL_LATCH_SET)
{
ResetLatch(MyLatch); / 起こされたら忘れずにリセット /
/ ここで本来の処理を実行 /
}
}

ここで重要なポイントが3つある。

1. `ResetLatch` を忘れないこと: ラッチは「フラグ」のようなものだ。一度セットされると、明示的にリセットしない限り、次の `WaitLatch` が即座にリターンしてしまう（＝ビジーウェイトしてしまう）。
2. `WL_POSTMASTER_DIED` をチェックする: プロセスが孤立しないための鉄則だね。
3. 適切な `WaitEvent` を指定する: デバッグするとき、この引数が何になっているかで、何がボトルネックか一発で分かる。ここを疎かにするエンジニアは、現場でトラブルシューティングする時に苦労するぞ。

—

実務上のアドバイス：ラッチと仲良く付き合うために

最後に、僕たちエンジニアがこの「ラッチ」をどう捉えるべきか、アドバイスを置いておくよ。

「Latch待ち＝悪」ではない: 勘違いされがちだけど、ラッチ待ちはプロセスが効率的に休んでいる証拠だ。本当に問題なのは、ラッチ待ち自体ではなく、その待ち時間が長すぎることで全体のスループットが低下しているケース（競合）だ。
OSのコンテキストスイッチを意識する: ラッチはOSのシステムコール（Linuxなら `epoll` など）に深く依存している。CPUの負荷が高い時や、I/O待ちが多発している時は、ラッチのウェイクアップ処理すら遅延することがある。OSレベルの監視（`vmstat` や `top` の `cs` 列）と、PostgreSQLの統計情報を合わせて見る癖をつけてほしい。
ソースを恐れない: PostgreSQLの `src/backend/storage/ipc/latch.c` を一度読んでみてほしい。驚くほどシンプルで、かつ泥臭い最適化の工夫が詰まっている。これが分かると、DBの「反応速度」に対する解像度が格段に上がるはずだ。

データベースはブラックボックスじゃない。ラッチのような地味な同期機構が、何万ものクエリを正確に、速く捌くための交通整理をしているんだ。

もし君が今、PostgreSQLの挙動で悩んでいるなら、一度「今、誰がラッチで待たされているのか？」を追いかけてみてくれ。そこには必ず、パフォーマンス改善のヒントが隠されているはずだ。

それじゃ、また。良いデータベースライフを！