【テクニカル・上級編】サブトランザクション – PostgreSQL

SAVEPOINTの深淵：PostgreSQLにおけるサブトランザクションの光と影

データベースの運用を長く続けていると、一度は「サブトランザクション」の罠に足を取られた経験があるはずだ。

アプリケーション層で `SAVEPOINT` を発行し、エラーをハンドリングして処理を継続する。一見すると、非常に洗練されたエラー制御手法に見える。しかし、この機能がPostgreSQLの内部でどのようなコストを支払い、時にパフォーマンスを劇的に劣化させるのか。今回は、この「見えざるコスト」について、少し深く掘り下げてみたい。

1. サブトランザクションは「軽量」ではない

多くのエンジニアは、サブトランザクションを単なるSQLレベルのマーカーだと思っているかもしれない。だが、PostgreSQLの内部構造を見ると、現実はもう少しシビアだ。

PostgreSQLにおけるサブトランザクションは、内部的には「サブトランザクションID（Subxid）」として管理される。これらは共有メモリ上の「CLOG（Commit Log）」に書き込まれる必要がある。問題は、サブトランザクションが多段にネストしたり、あるいはループ内で大量に生成されたりした場合だ。

ここで注意すべきなのが、Subxidのキャッシュ制限（`PGPROC`配列）だ。サブトランザクションが一定数（通常64個）を超えると、PostgreSQLはオーバーフロー状態となり、親トランザクションのXIDを共有する形での管理へ切り替わる。この切り替えが発生すると、トランザクション完了時に「誰がどの行をロックしているのか」という情報をより広範囲にスキャンせざるを得なくなる。結果として、`Commit` や `Rollback` の処理時間が肥大化するのだ。

2. なぜ「小分けのコミット」が悲劇を招くのか

よくあるアンチパターンとして、「大量のレコードを処理する際に、エラーを防ぐために1件ずつSAVEPOINTで囲む」という設計がある。

これをやると何が起きるか。
まず、`Subxid` の生成コストが積み重なる。そして何より致命的なのが、「サブトランザクションの数だけ、WALの書き込みと管理コストが増大する」という点だ。さらに、サブトランザクション内での更新は、ガベージコレクション（VACUUM）にとって厄介な存在になる。

サブトランザクションは、それがロールバックされたとしても、その内部で行われた変更が完全に消え去るわけではない。可視性（Visibility）の判定において、それらのSubxidを参照し続ける必要があるため、VACUUMは「そのサブトランザクションが完了したのか、まだ生存しているのか」を慎重に判断しなければならない。結果として、デッドタプルの掃除が遅れ、テーブルの肥大化を招くことになる。

3. トラブルシューティング：その「重さ」をどう検知するか

もし、特定のバッチ処理やAPIリクエストが、コミットの瞬間にだけ不自然にスパイクしているなら、サブトランザクションの過剰な利用を疑うべきだ。

確認の手順はシンプルだ。まずは `pg_stat_activity` を見るのも良いが、根本的な解決には `pg_subtrans` の統計情報を直接追うことはできないため、以下のアプローチを推奨する。

ログの観察: `log_min_duration_statement` を設定し、`COMMIT` に時間がかかっていないかを確認する。
イベントの追跡: `pg_stat_statements` を活用し、`SAVEPOINT` 発行回数とトランザクション全体の実行時間の相関を見る。
内部カウンタ: まだあまり知られていないが、`pg_stat_database` や `pg_stat_activity` から、サブトランザクションの深さや発生頻度を推測することは可能だ。

結論：使い所を見極める技術

もちろん、サブトランザクションが悪だと言っているわけではない。複雑なビジネスロジックをSQLレベルでアトミックに保つためには、SAVEPOINTは極めて強力な武器だ。

ただ、肝に銘じておいてほしいのは、「SAVEPOINTはトランザクションを分割する魔法の杖ではなく、コストのかかる管理機構である」ということだ。

ループの中で使うのではなく、どうしても分離が必要な論理単位にのみ限定する。あるいは、そもそもサブトランザクションに頼らなくて済むようなデータ設計、あるいはアプリケーション層での補完処理を検討する。

PostgreSQLは、その堅牢さゆえに、私たちが書いた「少しばかり効率の悪いコード」をも飲み込んで動いてくれる。だが、その恩恵に甘えすぎると、システムがスケールした瞬間に牙を剥く。

データベースエンジニアとしての矜持とは、こうした内部構造の機微を理解し、あえて「楽な道」を選ばないことにあるのではないだろうか。皆さんのアーキテクチャが、明日も軽快に動くことを願っている。