【実務・中級編】 MultiXact ID – PostgreSQL

やあ。PostgreSQLの深淵へようこそ。

今日は、多くのエンジニアが「なんとなく知っているけれど、深入りすると沼にハマる」でおなじみのMultiXact ID（マルチザックID）について話そうと思う。

パフォーマンスチューニングをしていて、「あれ、VACUUMが妙に重いな？」とか「`pg_multixact` ディレクトリが肥大化しているぞ？」なんて経験はないだろうか。その正体は、この小さな仕組みが頑張りすぎているせいかもしれないんだ。

—

MultiXact ID って結局なんなのさ？

PostgreSQLにおいて、行をロックする（`SELECT FOR UPDATE`など）とき、通常はトランザクションID（XID）を行ヘッダに書き込む。でもさ、もし「10個のトランザクションが同時に同じ行をロックしたい」と言い出したらどうなる？

行ヘッダは限られたスペースしかない。そこに10個分のXIDを詰め込むなんて無理ゲーだよね。

そこで登場するのが MultiXact ID だ。
これは、「複数のトランザクションが共同で保持しているロックのリスト」を指し示すIDのことだ。いわば、個別のXIDを束ねた「グループID」みたいなものだと思えばいい。

なぜこれが必要なのか：行レベルロックの共有

例えば、`SELECT FOR UPDATE`を複数のセッションで同時に実行するケースを考えてみてほしい。

— セッションA
BEGIN;
SELECT FROM products WHERE id = 1 FOR UPDATE;

— セッションB
BEGIN;
SELECT FROM products WHERE id = 1 FOR UPDATE;

このとき、PostgreSQLは行ヘッダの `xmax` フィールドに、これら複数のトランザクションを統合した「MultiXact ID」を書き込む。これにより、限られたスペースでも「誰がロックしているか」を正しく追跡できるんだ。

これがなければ、並列処理の限界はもっとずっと低いところにあったはずだよ。

実務で注意すべき「落とし穴」

このMultiXact ID、仕組みは素晴らしいんだけど、運用する側としてはいくつか気をつけなきゃいけないことがある。

1. 「MultiXactの周回」問題

トランザクションID（XID）の周回問題は有名だよね？実はMultiXact IDにも同じように「使い切る」という概念がある。これが行き過ぎると、最悪の場合データベースが停止する。
最近のPostgresなら自動でケアしてくれるけれど、大規模なシステムで頻繁にロックが発生する環境だと、このあたりの統計情報はたまにチェックしておいたほうがいい。

2. `pg_multixact` のディスク肥大化

ここが一番の盲点かもしれない。MultiXact IDの情報は、`pg_multixact/members` と `pg_multixact/offsets` というディレクトリに書き込まれる。
もし、ロックが解除されないまま放置されるトランザクション（長時間のトランザクションなど）が大量にあると、これらのファイルがどんどん溜まっていく。最悪、ディスクを圧迫してシステム全体を巻き込むことがあるんだ。

どう向き合うべきか：先輩からのアドバイス

現場でトラブルを防ぐために、僕がいつも気をつけていることを共有するよ。

「長期間のロック」は悪だと思え

`FOR UPDATE` をかけたまま、外部APIを叩いたり、重い計算をしたりするのは絶対にやめよう。それはMultiXact IDを無駄に生成し、VACUUMの足を引っ張る原因になる。ロックは「必要な最小限のスコープ」でサッと済ませるのが鉄則だ。

`pg_stat_activity` を愛せ

`SELECT FROM pg_stat_activity WHERE wait_event_type = ‘Lock’;`
これで、誰がロックを掴んで離さないのかを常に監視しておこう。「あ、こいつのせいでMultiXactが解放されていないな」という犯人が一目瞭然だ。

VACUUMのログを見る

もし運用していて「VACUUMが遅いな」と感じたら、`autovacuum` のログを深く観察してみてほしい。MultiXact IDのクリーンアップに時間がかかっているようなら、テーブルの設計やトランザクションの粒度を見直すサインだよ。

—

まとめ

MultiXact IDは、PostgreSQLが並列処理を効率よくこなすための「縁の下の力持ち」だ。普段は意識しなくていい仕組みだけど、ひとたび問題が起きると、その存在感はとてつもなく大きくなる。

「なんか最近ロック待ちが増えたな」「VACUUMが終わらないな」と思ったら、一度このMultiXactの存在を思い出してほしい。

データベースの内部構造を知ることは、トラブルを未然に防ぐ最強の武器になる。また何か深掘りしたくなったら、いつでも聞いてくれ。応援してるよ！