今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年8月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。
PostgreSQL 19 リリースにむけて
PostgreSQL 19 のリリースに向けた準備が進められています。PostgreSQL のメジャーリリースのリリースノートには、開発だけではなくレビューや開発報告など何らかの形での貢献者の名前リストが掲載されます。これらの名前について、表記揺れや重複、姓と名の順序などを確認する作業が行われました。なお、SRA OSS からも6名（８月時点）の貢献者の名前が含まれています。
一方で、リリース予定機能についてはやや緊迫した状況となっています。きっかけとなったのは、主要開発者の Robert Haas が AI（Claude）を利用して最近の不具合報告を整理し、多数の問題報告が集まっている機能を洗い出したことでした。対象となったのは、外部キー制約の高速化、REPACK / REPACK CONCURRENTLY コマンド、オンライン・データチェックサム有効化、SQL Property Graph Queries（SQL/PGQ）など、PostgreSQL 19 の主要機能です。議論では、それぞれについてリスクを評価し、機能全体または一部を差し戻すべきかどうかが検討されています。
興味深かったのは、こうした状況の背景として、「AI の普及によって従来よりも不具合が発見されやすくなった可能性がある」という意見も出ていたことです。PostgreSQL に限らず、OSS 開発のあり方が変化しつつあることを感じさせる議論でした。
SSIで相次いで報告された不具合
新機能ではなく、長年存在する機能に関する議論として、SERIALIZABLE 分離レベルを実現するための仕組みである、シリアライザブルスナップショット分離（SSI）に関する不具合が多数報告されました。ここ最近で SSI に関係する不具合が合計7件報告され、それぞれについて修正案が議論されています。報告された問題には、一意性制約をすり抜けて主キー重複が発生する可能性があるものや、SAVEPOINT の ROLLBACK 時に直列化異常の情報が失われる可能性があるものなどが含まれています。
SSI は PostgreSQL のトランザクション制御機構の中でも特に複雑な部分の一つです。これらの問題はもともと別々のスレッドで報告されたものですが、開発者の Andrey Borodin によって一つのスレッドへ整理されており、SSI の内部動作や課題を理解するための良い手がかりとなっています。
INSERT SELECT のパラレル化
性能改善に関する議論では、INSERT SELECT のパラレル化に進展がありました。
INSERT SELECT は、SELECT 文の結果をテーブルに挿入するための構文ですが、この SELECT の実行部分をパラレル化することで、大量データのロードを高速化しようという提案です。しかし、テーブルへの挿入時には、トリガや制約、デフォルト値、生成列などの処理が実行される可能性があり、それらを並列実行しても安全かどうかを確認する必要があります。この確認処理自体がオーバヘッドとなり、巨大なパーティションテーブルなどでは特にそれが顕著となります。
この問題に対し、ユーザ自身が事前にテーブルを「並列安全」と宣言する方式も提案されていましたが、その場合はユーザに全ての責任を負わせることになるため、好ましくありません。これに対して8月には、並列安全性を初回アクセス時に自動計算し、その結果をキャッシュする方法が提案されました。さらに、適切なキャッシュの無効化や、SELECTを並列実行した結果を一旦全て一時ファイルに保存してからテーブルに挿入する方式とのハイブリッドなど、さらなる改善の議論が続いています。
リカバリのパイプライン化
もう一つ注目した性能改善提案が、リカバリ処理のパイプライン化です。これは、PostgreSQL のリカバリ（クラッシュリカバリ、アーカイブリカバリ）時に WAL の適用を高速化するための提案です。
現在の PostgreSQL では、リカバリを担当する「startup プロセス」が、WAL の読み込み、デコード、適用をすべて担当しています。提案では、WAL のデコードを専用のバックグラウンドプロセスへ分離し、startup プロセスは WAL の適用に専念する構成となっています。つまり、WAL レコードの生成と消費を異なるプロセスで担当するパイプライン構造であり、これによって、リカバリ処理を20〜42%程度高速化できることが報告されています。
8月には、ロック競合によるオーバーヘッドの削減や、プロセス間シグナル通信の最適化、不正な WAL を検出した場合の責任分担などについて議論が行われました。リカバリアーキテクチャそのものを見直す提案として興味深く感じています。
VACUUMを妨げる要因を可視化する pg_xmin_horizon
運用に関する提案としては、新しいシステムビュー pg_xmin_horizon の議論に進展がありました。
PostgreSQL を運用していると、不要データを削除する VACUUM が期待通りに進まないことがあります。その原因としては、長時間実行中のトランザクションやレプリケーションスロット、プリペアドトランザクションなどが考えられます。現在も既存のシステムビューを組み合わせることで調査は可能ですが、それぞれの情報取得タイミングが異なるため、必ずしも正確な状況を把握できるとは限りません。
pg_xmin_horizon は、そのような要因を単一のビューで確認できるようにする提案です。このビューには、VACUUMを妨げている要因（バックエンドプロセス、レプリケーションスロット、プリペアドトランザクション、など）や、その要因によって VACUUMがどこで止められているか、要因となっているトランザクションのIDはなにか、などの情報が含まれています。8月には、表示情報の追加やテスト強化、ドキュメント整備などが進められていました。運用時のトラブルシューティングに役立つ機能として期待できそうです。