PostgreSQL 19の遅延はLLMのせいか — バックパッチ74%増と4機能revertを一次情報で検証

はじめに

PostgreSQL 19 のリリースが例年より遅れています。コミッターの Robert Haas 氏は、LLM でバグが見つかりやすくなり、修正とレビューが追いつかないことを原因に挙げ、この記事は Hacker News で 787pt を集めました。

GA は 11 月 19 日の予定で、例年より 1〜2 か月ほど遅れる見込みです。実務で大きいのは、ベータで案内された機能が外れたことと、既存バージョンのマイナー更新が膨らんでいることです。この記事では、公式発表と公開された数字で Haas 氏の説明を確かめ、確認すべき点を整理します。

何が起きたのか

Haas 氏によると、メジャーリリースはこれまで 9 月半ばから 10 月半ばに出ていました。今年の流れは次のとおりです。

日付	出来事
4 月 8 日	機能凍結
6 月 4 日	Beta 1。正式版は「9 月か 10 月ごろ」
8 月 27 日〜9 月 15 日	大きな機能の revert が続く
9 月 24 日	Beta 4。この時点では RC は 10 月上旬、GA も 10 月の可能性
10 月 15 日	RC 1
11 月 12 日	RC 2 と既存バージョンの定例更新（予定）
11 月 19 日	GA（予定。問題が見つからなければ）

Beta 4 の発表で revert と明記された主な機能は次の 4 つです。

SQL/PGQ（プロパティグラフクエリ）
UPDATE / DELETE の FOR PORTION OF
ALTER TABLE ... MERGE PARTITIONS / SPLIT PARTITIONS
データチェックサムのオンラインでの有効化・無効化

このほか、pg_get_role_ddl() などの DDL 取得関数も削除されました。リリースノート（10 月 9 日時点の版）にも、この 4 機能の記載はありません。Beta 1 の紹介記事を読んで期待していた人は注意が必要です。

数字を確かめる

Haas 氏が示すのは、各年の 4 月 8 日から 9 月 25 日までのコミット数です。「master のみ」は、Haas 氏の「わずかに減った」という記述に合わせて私が引き算した値です。同氏は計算方法を説明しておらず、ブランチ間で対応しないコミットがあれば誤差が出ます。

対象	2025 年	2026 年	増減
master 全体	1,037	1,443	+39.2%
リリース準備中のブランチ（18 → 19）	724	1,169	+61.5%
master のみ（引き算）	313	274	−12.5%
1 つ前のブランチ（17 → 18）	248	433	+74.6%

master だけで見るとコミットは減っており、増えたのは過去のバージョンにも当てる修正です。新機能の量そのものは、この数字だけでは分かりません。

別の角度の数字もあります。Josh Andrews 氏が pgsql-hackers に投稿した集計（9 月 18 日時点）です。

8 月のマイナーリリースの項目は 142 件で、2025 年から 2026 年初めの定例は 63〜78 件
CVE は以前の 1 リリース 2〜3 件から、5 月に 14 件、8 月に 29 件へ（The Build は 5 月のリリースを 11 件と記載しており、数え方の違いは未確認）
コミットメッセージで AI の関与を明かした stable ブランチの修正は 26 件で、すべて 2026 年 4 月以降。うち 22 件は AI ツールがバグを見つけたと明記

LLM だけで説明できるのか

Haas 氏の説明は 2 段階です。バグが増えれば修正に時間がかかります。LLM は修正案も書けますが、正しいとは限らず、人間のレビューが必要です。そしてレビューの時間が過去のバージョンの修正に取られ、19 から何を外すかの判断も遅れました。

those humans have not gotten any smarter between 2025 and 2026.

ただ、確認できる範囲では、因果がすべて裏付けられているわけではありません。

まず、MERGE / SPLIT の revert について、リリース管理チームの依頼とコミットが挙げる理由は設計上の問題で、LLM には触れていません。次に、Andrews 氏は pgsql-hackers と pgsql-bugs の流量とバグ報告の総量に大きな変化はないとしています。Haas 氏の「大量の人が LLM で見つけたバグを報告している」という書きぶりとは、印象が異なります。一方で、AI の関与を明かした新規スレッドは 6 月より前の 1% 未満から、8 月には約 8% まで増えました。どちらも自己申告にもとづく数字なので、実際はこれより多い可能性があります。

私の読みでは、LLM の影響は「報告の数」より「修正すべきバグの比重」に出ています。報告の総量が大きく変わらないのに、CVE と修正のコミットが増えているからです。ただしこれは公開された数字からの推測で、因果を測った調査はまだ見当たりません。なお Haas 氏はコミッターのミスが増えた可能性にも触れていますが、それが主な原因だと信じている関係者はいないだろうと書いています。

他の OSS でも同じ問題が語られています。Cloud Security Alliance のノートは、curl の報奨金終了や Google OSS VRP の受付停止などをまとめ、原因を低品質な報告と、有効な発見に修正が追いつかないことの 2 つに分けています。後者は証拠がまだ薄いとも書いています。PostgreSQL の事例は、その後者を考える材料になります。

エンジニアへの影響

機能の前提を見直す: SQL/PGQ、FOR PORTION OF、パーティションの MERGE / SPLIT を前提にした移行計画は組み直します。5 月の記事のように「19 に入る」と書いたものが残っているので、リリースノートで確認してください。REPACK（CONCURRENTLY で排他ロックなしの再構築）や pg_plan_advice はリリースノートに載っています。JIT が既定で無効になる変更もあるので、分析系のクエリは比較しておきたいところです。

マイナー更新を軽く見ない: RC 1 の発表は、11 月 12 日の定例更新に修正が多く含まれるため、RC 2 を追加すると説明しています。8 月の 142 件を考えると、マイナー更新は「再起動するだけ」で済まない場合もあります。リリースノートの確認、ステージングでの検証、再起動の手順を、定例作業として回せるようにしておくのが現実的です。

GA 当日に移らない: 私なら、19 への移行は 11 月 19 日の GA の直後には行いません。以前のバージョンからの移行には pg_upgrade か pg_dump / pg_restore が必要なので、検証環境で試してから、最初のマイナーリリースを目安に判断します。RC から GA への手順は RC 1 の発表に書かれていないので、RC を試す場合は別途確認してください。日程も問題が見つかれば動きます。

自分のプロジェクトでも同じことが起きる: LLM でコードベースを走査すると、見つける側だけが速くなります。優先順位の付け方とレビューの担当を決めずに始めると、指摘が積み上がるだけになります。

まとめ

PostgreSQL 19 は 11 月 19 日の GA を予定しており、さらに延びる可能性も残っています。Haas 氏も今回の遅れは大きな問題ではないとする一方、「40 年分のバグ」に追いつけるかは分からないと書いています。コミット数と CVE の増加は確認できますが、すべてが LLM によるとまでは言えません。当面は、外れた 4 機能の確認と、大きくなったマイナー更新への備えから始めるのがよさそうです。

今日のその他のニュース

GMOトラスト・ログインで 4 万 5,030 人分が漏えい: 2,492 社分の氏名やメールアドレスなどが対象で、パスワードと多要素認証の情報は含まれないとのことです。2017 年ごろに公開領域へ変更したストレージのリンクに署名も期限もなく、約 9 年間取得できる状態でした。（ITmedia）

Reddit がログイン前提の方針へ: CEO が株主宛ての書簡で表明し、第 4 四半期に米国以外の一部市場でテストを始めます。ログインが必要な範囲は未定で、RSS の扱いも記事には書かれていません。（INTERNET Watch）