【実務・中級編】 CLOG (Commit Log) – PostgreSQL

「PostgreSQLのパフォーマンスを追いかけていたら、なぜか『CLOG』という言葉に突き当たった」。そんな経験、ないでしょうか？

データベースの深淵を覗こうとすると必ず現れるこのCLOG（Commit Log）。今回は、PostgreSQLの心臓部の一つであるこの仕組みについて、少し現場の視点から紐解いてみようと思います。

—

一言でいえば、「このトランザクション、結局どうなったの？」を記録しておくための、超高速なビットマップです。

PostgreSQLはMVCC（多版同時実行制御）を採用していますよね。テーブルのタプル（行）には `xmin` と `xmax` という隠しカラムがあって、「どのトランザクションが書き込み、どのトランザクションが削除したか」が記録されています。

でも、考えてみてください。データベースが動いている最中、何千ものトランザクションが同時に走っています。タプル一つひとつに「コミット済みですよ」と書き込んでいたら、I/Oがパンクしてしまいますよね。

そこで登場するのがCLOGです。

この3つのステータスを、各トランザクションID（XID）ごとに2ビット使って表現しています。共有メモリ上にキャッシュされ、必要に応じてディスク（`pg_xact` ディレクトリ）に書き出される、いわば「トランザクションの通知表」のようなものです。

普段の開発で「CLOGを意識してコードを書く」ことはまずありません。しかし、PostgreSQLが極端に重くなったときや、大規模なVACUUMの問題に直面したとき、CLOGの挙動を知っていると景色が変わります。

例えば、`pg_xact` ディレクトリ。ここが肥大化しすぎてディスクを圧迫したり、あるいは「トランザクションIDの周回問題（Transaction ID Wraparound）」に直面したとき、CLOGの理解は必須の知識になります。

PostgreSQLのXIDは32ビット。約40億個しかありません。これを超えるとIDが一周してしまい、過去のデータが突然「未来のデータ」として扱われるという悪夢が待っています。

これを防ぐのがオートバキュームの重要な役割ですが、CLOGはまさにその「どの古いトランザクションを消していいか」を判定するための重要な参照先です。CLOGが正しく機能していない、あるいはバキュームが追いついていない環境では、この管理領域がボトルネックになることもあります。

—

もしトラブルシューティングをするなら、まずは以下の視点を持つといいでしょう。

PostgreSQLの内部関数を使って、特定のXIDのステータスを確認できます。

— 現在のトランザクションIDを取得
SELECT txid_current();

— 特定のXIDがコミット済みか確認（内部的にはCLOGを参照している）
SELECT txid_status(12345);

`$PGDATA/pg_xact` の中身を見てください。ここが異常に巨大化している場合、それは「終わっていないトランザクション」がどこかで放置されている可能性が高いです。

ターミナルで確認
ls -lh $PGDATA/pg_xact/

もしここがパンパンなら、`pg_stat_activity` を見て、何日も放置されているアイドル状態のトランザクションがないか、あるいはバックエンドプロセスがハングアップしていないかを確認するのが定石です。

—

CLOGはPostgreSQLの「ガチ」なコア部分です。ここをいじるパラメータは基本的にありませんし、弄ろうとするものでもありません。

でも、「MVCCの裏側には、こういう効率的な管理の仕組みがあるんだ」ということを知っているだけで、クエリの実行計画を見たり、バキュームの挙動を追ったりする時の解像度がグッと上がります。

「なぜPostgreSQLはこんなに高速なのか？」という問いに対する答えの一つが、この「CLOGによる軽量なステータス管理」です。

もし次に、`VACUUM` が終わらない！とか、`wraparound` の警告が出た！なんていう事態に遭遇したら、ぜひ「あぁ、CLOGが頑張ってくれてるんだな（あるいは詰まってるんだな）」と思い出してください。

データベースの内部構造を知ることは、相棒の「機嫌」を知ることに似ています。これからも、PostgreSQLという優秀な相棒と長く付き合っていきましょう。

では、また次回の深掘りでお会いしましょう！