PostgreSQLの開発グループは10月15日、次期メジャー版「PostgreSQL 19」のリリース候補版(RC1)を公開し、正式版(GA)を11月19日に出す予定だと発表しました。例年は9月下旬に出るため、約2カ月遅れです。遅れの一因として、主要コミッターのPeter Eisentraut氏は、LLM(大規模言語モデル)を使ったコードレビューが欠陥を以前より速く大量に見つけるようになったことを挙げています。グラフ問い合わせ(SQL/PGQ)など8〜10の主要機能がベータ版の公開後に取り下げられており、PostgreSQLを使う開発・運用チームは、新機能を前提にした移行計画を見直す必要があります。
RC2を挟んで11月19日にGA
RC1の告知によると、11月12日にRC2を出し、問題がなければ11月19日にGAとします。RC2は既存バージョン向けの定例アップデートと同じ日です。リリースチームのJonathan S. Katz氏は10月10日の開発者向けメーリングリストpgsql-hackersへの投稿で、旧ブランチに修正が大量にたまっているため、GAの前にRC2で取り込むと説明しました。そのうえで「異例のメジャーリリースのサイクルだった」と認めています。
なぜ差し戻しが増えたのか
Eisentraut氏は10月9日のブログで、ベータ開始後に差し戻した主要機能は数え方によって8〜10個だと書いています。通常は1サイクルに1つ程度なので、明らかに多い数字です。理由は機能ごとに違うとしつつ、次の点を挙げました。
- 設計上の根本的な欠陥があり、ベータ期間中に直すのが難しかった機能がある
- LLMを使ったコードレビューで問題がすぐ見つかるようになり、何年も前に書かれたコードにも高い基準が適用された。1回のレビューで約40件の欠陥報告が並んだこともある
- 4月の機能凍結から8月のセキュリティリリースまで、中心的な開発者がセキュリティ修正に追われ、ベータ期間のレビューやテストが手薄になった
同氏は、差し戻したコードは「バイブコーディング」(AIに任せきりで書く手法)が可能になる前に書かれたもので、AIが書いたせいではないと強調しています。原因は「AIが書いたコード」ではなく「AIが読んだコード」の側にある、という構図です。ドメイン型、パーティション、ビュー、トリガーなど多くの機能と組み合わさる機能は人手で網羅的に試すのが難しく、LLMを使ったファジング(大量の入力を自動生成して不具合を探すテスト)を機能開発の標準工程にすべきだとも提案しています。
セキュリティ面でも同じ傾向が見えます。Snowflakeの開発者アドボケイトによる9月16日の解説によると、8月のPostgreSQL 18向けパッチでは28件のCVE(脆弱性の識別番号)が修正されました。以前は1回あたり数件だったとしています。
何が入り、何が外れたか
同じ解説では、差し戻された機能としてSQL/PGQ、パーティションのMERGE/SPLIT、UPDATE/DELETE FOR PORTION OF、GROUP BY ALL、TOAST圧縮の既定値のlz4への変更、オンラインでのデータチェックサム有効化などが挙がっています。多くはPostgreSQL 20で再び入る見込みです。未解決事項の一覧でも、GRAPH_TABLEやPGQのカタログ表現などが「差し戻し」で決着しています。
残る機能では、テーブルをロックせずに領域を回収できる REPACK (CONCURRENTLY) が目玉です。RC1では細かな挙動の変更もあり、COPY (query) TO ... (FORMAT json) のJSONのキーが、テーブルの列名ではなく問い合わせの列名(別名を含む)になりました。
日本の開発・運用チームにとっての意味
国内でもPostgreSQLは業務システムやクラウドのマネージドDBで広く使われています。マネージドサービスは本家のGAから遅れて新版に対応するのが通例なので、19を使えるようになる時期も後ろにずれると考えられます。年度内に19へ上げる計画を立てていた場合は、日程と、どの新機能を前提にしていたかを確認し直す必要があります。特にSQL/PGQやパーティションのMERGE/SPLITを当てにしていたなら、20まで待つことになります。
もう1つの示唆は、LLMによるレビューが品質の基準そのものを押し上げているという点です。GitHubのAI Scan for PRsのように、AIによる検査はすでに日常の開発に入り始めています。導入すると、これまで見過ごしていた指摘が一度に大量に出る可能性があります。PostgreSQLのように、修正しきれない指摘を抱えたまま期日を迎える事態は、自社のプロジェクトでも起こりえます。リリースの直前ではなく、開発の早い段階からAIレビューを回すほうが安全だと考えられます。なお、PostgreSQLにはAIを使った貢献に関する公式方針はまだなく、近く定める見込みだと前述の解説は伝えています。
次にやること
- 19への移行予定があるなら、RC1を検証環境に入れ、COPY ... FORMAT json など挙動が変わった箇所を確かめる。本番はGA後、少なくとも最初のマイナー版まで待つのが無難
- SQL/PGQなど差し戻された機能を前提にしていた設計は、20(2027年)を待つか代替手段を選ぶ
- 自社でAIレビューを導入する場合は、指摘の件数が急増する前提で、リリース直前ではなく開発の初期から回す
