PostgreSQL 19はなぜ10年続いた秋リリースの鉄則を破ったのか LLMの脆弱性発掘ラッシュと31人のコミッターが直面した限界

2016年のPostgreSQL 9.6から昨年のPostgreSQL 18に至るまで、世界で最も信頼されるオープンソースRDBMSは、10メジャーバージョン連続で「9月中旬から10月中旬」という秋のリリースウィンドウを一度も外したことがありませんでした。しかし今年、PostgreSQL 19はその慣例を異例のかたちで破りました。Beta 4とRC 2という2度の「延長戦」を追加した結果、公式の一般提供（GA）予定日は 2026年11月19日 へと延期され、テスト終盤にはすでにマージ済みだった8〜10件の大型新機能が相次いで切り捨てられたのです。

リリースの足並みを乱したのは、世間が真っ先に連想するような「AIが粗悪なコードを大量生産したから」ではありません。むしろ正反対で、世界中のセキュリティチームやカーネルメンテナが手にしたLLMのバグ発掘スピードが速すぎたのです。サポート対象ブランチにおける年間の実在するセキュリティ脆弱性（CVE）が5倍以上に跳ね上がり、既存の旧本番ブランチへ世代を超えて適用するバックパッチ（back-patch）が1年で 74.6% も急増するなか、世界にわずか 31名 しかいないアクティブなコミッターたちは、人間のコードレビューとリグレッション（回帰バグ）検証におけるスループットの限界に初めて正面から突き当たりました。

1. 10年続いた秋リリースの鉄則崩壊と2度の異例な「延長戦」

3度にわたり後退した秋のリリーススケジュール

本番環境のPostgreSQLクラスタを日頃運用しているエンジニアなら、スイス時計のように正確な年次リリースサイクルにすっかり慣れ親しんでいるはずです。公式のバージョンライフサイクル記録をひもとくと、過去10年間で連続する10個のメジャーバージョンの初回リリース日は、すべてわずか35日間の狭い期間に寸分違わず収まっています。最も早かったのが9月14日（PG 16）、最も遅かった年でも10月18日（PG 11）を超えていません。公式の静的な開発ロードマップページを開いてみても、メジャーバージョンの予定欄には10月下旬に至るまで更新が追いつかず「October 2026」の文字が残されていたほどです。

実はほころびの兆候は、今年の初夏にはすでに表れていました。昨年のPG 18と同様、PostgreSQL 19は 4月8日 12:00 UTC に最後のCommitFestによるフィーチャーフリーズ（機能凍結）を予定通り完了しました。ところが、昨年は5月8日に登場した最初のテスト版Beta 1が、今年は 6月4日 までずれ込み、スタート時点からすでに1か月近く遅れていたのです。

9月に入ると、リリース調整役を務めるコアチームメンバーのJonathan S. Katz氏が pgsql-hackers メーリングリストに3通のスケジュール通知を相次いで投稿しました。そこには、10年来の慣例を死守しようと奮闘しながらも最終的に後退を余儀なくされたコミュニティの軌跡が生々しく記録されています。

• 9月3日（Beta 4の異例追加）：通常サイクルではBeta 3までで完了するところ、9月24日に異例となる第4のテスト版Beta 4を追加リリースすると発表しました。同氏はメールの中で、この措置は「最近押し寄せ、対処に余分な時間を要している大量の不具合報告」に対応するためだと率直に述べ、脚注には単一リリースで28件ものCVEを修正した 18.6 のリリースノートを具体例として直接添えています。この時点では、まだ10月末までのGA死守が目標でした。
• 9月28日（10月末ギリギリを狙う強行日程）：Beta 4の公開から4日後、チームはタイトな最終スプリント日程を提示しました。10月15日にRC 1を出し、RC 2を設けずに10月29日にそのまま正式版をリリースすることで、11月の定例マイナーバージョン更新までに2週間のバッファを確保しようという計画でした。
• 10月10日（RC 2の追加と11月への正式延期）：RC 1公開まで残り5日となった段階で、リリースチームはついに無理を通さない決断を下し、11月12日にRC 2を追加すると発表しました（第4四半期の定例マイナーリリースと同日公開）。まず各旧保守ブランチに新たに積み上がった大量の修正を取り込んで1週間検証し、そのうえで 11月19日 にPostgreSQL 19正式版をリリースする運びとなったのです。10月15日のRC 1公式アナウンスでこの日程が正式に確定し、同時に「ブロッカーとなる問題が見つかった場合はさらなる延期やRC追加もあり得る」との留保が添えられました。

61.5%増と74.6%増が示す2つのGitコミット台帳

なぜ旧ブランチ向けの修正パッチが、新しいメジャーバージョンを10月の枠から押し出すほど膨れ上がったのでしょうか。

10月21日、ベテランコミッターのRobert Haas氏（現Databricks所属）がNeonの公式ブログに『Postgres 19 is late, and it's AI's fault（Postgres 19が遅れているのはAIのせいだ）』という直球のタイトルで長文の振り返り記事を公開しました（10月30日に個人ブログへ転載されると業界中で大きな反響を呼びました）。同氏は記事の中で、2025年と2026年の完全に同一な集計期間（毎年4月8日のフィーチャーフリーズから9月25日まで）における公式Gitリポジトリのコミット集計データを突き合わせています。

ここ数日の二次報道では「長年潜んでいた古いバグの発掘」と「バックパッチの60%急増」が混同されがちですが、Haas氏が集計した元のブランチ別データを分解して見ると、実際の数字はさらに衝撃的です。

集計軸（毎年4月8日〜9月25日）	2025年（PG 18サイクル）	2026年（PG 19サイクル）	前年比変化	エンジニアリング上の実態
master ブランチ総コミット数	1,037回	1,443回	+39.15%	リポジトリ全体のコード変更スループット総量
master のみへの純粋な新規開発コミット	313回	274回	-12.46%	次期メジャーバージョン向けの新機能開発はむしろ微減
開発中の次期安定ブランチへのコミット	724回（REL_18_STABLE）	1,169回（REL_19_STABLE）	+61.46%	v19新機能の修正・撤回および master からの同期バックパッチを含む（「60%超」の内訳）
リリース済み旧本番ブランチへの世代横断バックパッチ	248回（REL_17_STABLE へ）	433回（REL_18_STABLE へ）	+74.60%	既存の本番稼働バージョンに影響する過去のバグ修正の実数（1年で約4分の3も急増）

数字が物語る事実は明快です。コミッターたちが今年書いた新機能のコード量は増えるどころか12.5%減っています。リポジトリをパンク寸前に追い込んだ正体は、master から開発中の安定ブランチへ流し込まれた1,169回のコミット（+61.46%）であり、とりわけリリース済みの旧本番バージョンへ少なくとも1世代以上さかのぼってパッチを当てなければならない積年のバグ修正が、わずか1年で 74.60% も跳ね上がったことにあるのです。

原因は「Vibe Coding」ではなかった

「AIのせいでデータベースがリリース延期」「大量の新機能がロールバック」と聞くと、多くの人が真っ先に疑うのは「開発者までAIを使ったノリ任せの実装（Vibe Coding）に走り、生煮えのコードをカーネルに押し込んだのではないか」という点でしょう。

もう一人のコアチームメンバー兼コミッターであり、EDBのバイスプレジデントを務めるPeter Eisentraut氏（同氏自身、今年ロールバックされた複数の機能の作成者やコミッターでもあります）は、10月9日に公開した『The reverts will continue until morale improves（士気が改善するまでリバートは続く）』の中で、この推測を明確に否定しました。

同氏の指摘によれば、今年影響を受けて撤回された機能の大部分は、LLMによるコードレビューが実用レベルに成熟するよりもずっと前に実装・コミットされたものでした。コミッターがコードをマージする際の慎重な判断基準も例年と何ら変わっていません。激変が起きたのはその反対側——「実効的な品質ハードルが、機能が書かれてコミットされた後に、事後的に引き上げられた」という点なのです。

これまでであれば、複雑なデータベース機能に潜むエッジケースの組み合わせバグは、正式リリース後の 5年間 にわたり、世界中の多様な極限ワークロードにさらされるなかで少しずつ表面化し、コミュニティも順を追って計画的に修正していくことができました。ところが今年は、世界中の研究者や開発者が最先端のLLMを手にソースコードの補助レビューやファジングを一斉に仕掛けたため、本来なら5年かけて分散して見つかるはずだったロングテールの潜在不具合が、たったひと夏の間に一気に圧縮・起爆されてしまったのです。

2. 2026年の脆弱性ストームと20年間潜伏したコードの死角

AIスパム報告ではなく本物の高深刻度脆弱性の奔流

今年のオープンソース界隈は、いわゆる「AIゴミ報告（AI Slop）」に散々悩まされてきました。1月末にはcURLがHackerOne上でAI生成の虚偽報告が氾濫し、有効率が5%を割り込んだことを受けてバグバウンティ制度を閉鎖しました。8月下旬にはQEMUリポジトリに対し、単一アカウントが10分足らずの間に未検証のAI生成UBSanエラー報告を132件も投下する事態が発生し、Red Hatのベテランメンテナからメンテナの認知帯域を標的にした「DoS攻撃（サービス拒否攻撃）」と公に断罪されたほどです。

そのためHacker Newsの議論でも、外部の開発者の多くは当初「PostgreSQLも低品質なAIハルシネーション報告に忙殺されたのだろう」と考えていました。しかしPGDG公式のセキュリティ脆弱性一覧を開けば一目瞭然ですが、PostgreSQLを襲ったのは偽報告の嫌がらせなどではなく、極めてSN比の高い本物の「脆弱性ストーム（Vulnpocalypse）」でした。

非公開のセキュリティ窓口（security@postgresql.org）の裏側でどれほどの誤報が弾かれたかは公表されていませんが、セキュリティチームが厳密に再現を確認し、サポート対象ブランチ（PG 14〜18）への影響を認定して正式に採番された実在のCVE件数だけを見ても、グラフの傾きは完全に垂直へ近づいています。

• 2023年 通年：7件のCVE
• 2024年 通年：7件のCVE
• 2025年 通年：7件のCVE
• 2026年 最初の定例更新3回分（8月時点）：44件のCVE（加えて235件超の一般バグ。11月12日公開予定の第4回分はまだ含まず）

3年連続で定規で引いたように安定していた「年間7件」が、2026年は第3四半期までの時点で一気に 44件 へと跳ね上がり、前年比 528.6%増（例年の年間平均の6.29倍）を記録しました。今年の四半期アップデート3回を時系列で並べると、その圧力がいかに波状的に高まったかが分かります。2月12日（18.2 バッチ）でのCVE修正は5件、5月14日（18.4 バッチ）では11件に増え、そして8月13日（18.6 バッチ）では単一リリースとして過去最多となる 28件のCVE と110件超の一般バグが一挙に修正されました。しかもその約半数は、CVSS 8.8クラスのヒープバッファオーバーフロー、整数オーバーフロー、型混乱（Type Confusion）、あるいは任意コード実行につながる高深刻度の脆弱性だったのです。

謝辞欄に並ぶAIセキュリティ部隊と「脆弱性の同時衝突」

今年の3回のセキュリティアドバイザリや 18.6 公式リリースノートの謝辞欄を読むと、まるで世界の最先端LLMと自動脆弱性発掘エンジンの実戦ランキングを眺めているかのようです。

• Claude & Anthropic Research：5月にCalif.ioと共同で hstore のバイナリ入力におけるスタックオーバーフロー（CVE-2026-6479）を報告。8月にはセキュリティ研究者Ben Morris氏と連名で、ltree のヒープバッファオーバーフロー（CVE-2026-16239）、EXTRACT() 逆解析時のスーパーユーザSQLインジェクション（CVE-2026-15741）、ロール一覧の逆解析インジェクション（CVE-2026-15742）という高深刻度脆弱性3件を一挙に報告しました。
• OpenAI Codex Security：Amy Burnett氏とOpenAIセキュリティ研究チームが、18.6 において tsquery の境界外メモリ読み取りおよびスタックオーバーフロー（CVE-2026-14669）、btree_gist のヒープオーバーフロー（CVE-2026-16238）、統計情報計算における任意メモリ読み取り（CVE-2026-14680）に立て続けに名を連ねました。
• 世界各地の特化型AI監査エンジン：自動コード監査チームの Xint Code（累計5件のCVEにクレジット）、サイバーセキュリティ新興企業の AISLE（年初に自律システムでOpenSSLの単一リリースに含まれる全12件のCVEを独占発見した実績を持つ）、Tencent Xuanwu Lab（騰訊玄武実験室）XlabAIチームと自動脆弱性発掘エンジンAtuinの連合（CVE-2026-6475）、Ant GroupのAntAISecurityLab（復旦大学との共同）、さらに TrendAI ZDI までがずらりと顔を揃えています。

世界中のセキュリティチームが一斉にトップクラスのモデルを動員し、30〜40年の歴史を持つ同じC言語コードベースをスキャンした結果、時代を象徴する2つの現象が生まれました。

1つ目は、20年前の古い死角が根こそぎ暴かれたことです。今年2月に修正された高深刻度の脆弱性 CVE-2026-2005（CVSS 8.8、暗号文の提供者がデータベースOSユーザ権限で任意コード実行を行える問題）は、Xint CodeチームがAI監査を用いて発見しました。Git/CVSの履歴をさかのぼると、ヒープバッファオーバーフローを含むこのコードはなんと 2005年 に暗号化拡張モジュール pgcrypto とともにメインリポジトリへ取り込まれ、無数の本番環境で実に20年以上も潜伏し続けていました。歴代の人手による監査も従来のファジングもすり抜けてきた欠陥を、今年ついにLLMが一目で見抜いたのです（なお同時期にXint Codeは、MariaDBからも2004年に混入し22年間潜伏していたスタックオーバーフロー脆弱性 CVE-2026-21576 を掘り起こしています）。

2つ目は、10を超えるチームが同じ穴に同時到達する「脆弱性の衝突」です。従来のセキュリティ研究では、独立した2つのチームが同じ月に同じ深層バグを引き当てるだけでも珍しい偶然とされてきました。ところが今年5月に公開された CVE-2026-6473（jsonb_populate_recordset の型混乱（Type Confusion）による任意コード実行）の謝辞リストには、異例となる 10組 もの独立した報告者が並びました。さらに8月の CVE-2026-14669 では共同クレジットが 11組 にまで更新されています（OpenAI Codex SecurityとAntAISecurityLabの双方が含まれています）。LLMは脆弱性発掘の敷居を下げただけでなく、異なるチームを似通った推論経路へと導き、同じ歴史的盲点へ一斉に収束させたのです。

3. 31人の人間ゲートキーパーの処理限界と3度のリグレッション事故

なぜAIが見つけた穴をそのままAIに直させないのか

これほどLLMがバグ探しに長けているなら、なぜ修正パッチの生成やコードレビューまでそのままAIに任せてしまわないのでしょうか。

その答えは、「生成の許容誤差」と「カーネルへの最終責任」の間に横たわる巨大な断絶にあります。PGDG公式のコミッター名簿によれば、世界中の何百万もの基幹システムを支えるPostgreSQLメインリポジトリに対して、直接 git push する権限を持つアクティブなコミッター（Committer）は合計でわずか 31名 しかいません。

しかも、この31名の役割は極度に重複しています。うち 20名 はPostgreSQL Security Teamを兼務しており、詳細を外部に伏せたまま非公開の脆弱性報告を検証し、PG 14、15、16、17、18という5つのサポート対象メジャーバージョン向けに手作業でバックパッチを書き分け、適合させなければなりません。さらに今年のメジャーリリースの品質を統括するリリース管理チーム（RMT）に至ってはわずか 3名（Nathan Bossart氏、Heikki Linnakangas氏、Melanie Plageman氏）しかおらず、最初の2名は今年発生した複数の高深刻度CVEの修正コード執筆そのものも最前線で自ら担当していました。

Robert Haas氏は振り返り記事の中で、胸に刺さる率直な現実を語っています。「LLMは修正パッチの下書きを作ることはできるが、それが常に正しいとは限らず、PostgreSQLの品質基準を満たしているとも限らない。結局は人間がレビューしてコミットしなければならず、その人間たちは2025年から2026年の間に急に賢くなったわけではないのだ。」

PGXのプリンシパルコンサルタントであるChristophe Pettus氏も、『19th Nervous Breakdown』の中で象徴的な実例を紹介しています。今年のテスト期間中、ベテランコントリビュータのThom Brown氏がClaudeを使って新機能 REPACK を調査し、論理デコーディングのシナリオでクラスタ全体がクラッシュする深刻なバグを見事に特定しました。その際Claudeは1行ずつの修正コードを2か所提案したのですが、原著者のAntonin Houska氏がレビューしたところ、AIが示した2か所の修正のうち1か所は誤っており、そのままマージしていれば内部状態をかえって破壊してしまう内容だったのです。

たとえパッチのロジック自体が数行で済むとしても、ソフトウェア工学における「固定オーバーヘッド（fixed overhead）」は省略できません。Peter Eisentraut氏が試算した通り、目の前に突如として40件の不具合リストが積み上がったとき、1件あたりの修正が平均 3行のコード だったとしても、最小再現ケースの構築、メーリングリストでの境界条件の往復議論、リグレッションテストの追加、さらには5〜6世代の過去ブランチをまたいだ手動コンフリクト解消とマルチプラットフォームBuildfarmの監視まで、すべての工程がこの31名の認知帯域を確実に削り取っていきます。

半年で3度のトラブルと高頻度バックパッチが招いた二次リグレッション

さらに厄介なことに、極度のプレッシャー下で5つの旧本番ブランチへ数百件ものセキュリティ修正・バグ修正パッチを高頻度で流し込んだ結果、今年上半期にはPostgreSQLが長年誇ってきたマイナーバージョンの安定性に目に見える揺らぎが生じました。

1. 2月の予定外緊急リリース（18.3）：5件のCVE修正を含む 18.2 シリーズを2月12日に公開したわずか4日後、セキュリティパッチがマルチバイト文字列処理において substring() の深刻なリグレッションを引き起こしていることが判明しました。公式チームは予定外のアップデートを余儀なくされ、2月26日に火消しとして 18.3 / 17.9 / 16.13 / 15.17 / 14.22 を緊急リリースしました。
2. 5月のスタンバイWAL再生時セルフデッドロック混入：5月14日公開の 16.14 / 15.18 / 14.23（11件のCVE修正を含む）において、PG 14〜16のスタンバイノードが旧バージョンのプライマリからWALログを再生する際にセルフデッドロック（self-deadlock）に陥るリグレッションが意図せず混入し、完全な解消は8月まで持ち越されました。
3. 8月の異例となる 18.5 破棄と欠番リリース：8月中旬、18.5 のパッケージング（wrap）を完了した直後、一般公開直前の最終段階で新たなリグレッションが発覚しました。チームは 18.5 というバージョン番号そのものを破棄し、8月13日に番号を飛ばして 18.6 を公開する異例の対応を取りました。

上半期のこの3度のヒヤリハットをつなぎ合わせれば、10月10日にリリースチームが下した決断の重みがはっきりと理解できます。11月12日の第4四半期定例アップデートとともに再び大量のバックパッチが着弾するのを前に、10年連続の秋リリース記録を破ってでもRC 2を1回増やし、世界中の環境で1週間の公開検証を経る道を選んだのです。十分に焼き込み（バーンイン）されていない大量の低レイヤ変更を、そのままPostgreSQL 19の初回正式版に紛れ込ませるわけにはいかなかったのです。

4. Claude主導の「高リスクパッチ査定」と安定性を守る機能撤回

ロールバックの波を引き起こした1通のメール

4月から8月にかけて吹き荒れた「脆弱性ストーム」は、旧ブランチを揺さぶっただけでなく、本来ならベテランコミッターたちがPG 19の新機能を磨き上げるはずだった貴重な夏の時間を奪い去りました。8月中旬に28件のCVEを抱えた 18.6 の出荷をようやく乗り切り、リリース候補（RC）フェーズを目前に控えたPG 19を振り返ったとき、残された修正ウィンドウはほとんど底を突いていました。

興味深いのは、カーネルメンテナたち自身もまたLLMを「外科メス」として手に取ったことです。8月25日、Robert Haas氏は pgsql-hackers で scary patch contest（高リスクパッチ査定）と題したスレッドを立ち上げました。同氏はAnthropic Claudeを使って4月8日のフィーチャーフリーズ以降における各新機能のバグ修正回数と不具合の性質を体系的に監査させ（メール内では「LLMのあまりに辛辣なコメントはいくつか削っておいた」と冗談めかして添えています）、最も冷や汗をかかせる6つのパッチセットを名指ししました。

• REPACK / REPACK CONCURRENTLY：フリーズ後に累計28回の修正が入り、データ消失の恐れがある不具合を含んでいました。
• データチェックサムのオンライン有効化・無効化：約25回の実質的な修正が入り、多くはステートマシンの不備でしたが、「破損検知機能そのものが正常データを破損と誤検知する」致命的な故障モードまで見つかりました。
• UPDATE / DELETE ... FOR PORTION OF（テンポラル更新・削除）：17回の修正が入り、うち3件は行レベルセキュリティ（RLS）や権限チェックをバイパスするセキュリティ脆弱性でした。
• SQL/PGQ プロパティグラフクエリ：17回の修正。
• 外部キーのファストパスおよびバッチ検査：約16回の修正が入り、境界外書き込みや5種類の誤った制約適用が含まれていました。
• postgres_fdw の統計情報インポート：フリーズ当日に滑り込みでマージされたわずか単一ファイルの contrib コードにもかかわらず、その後に7回もの修正を要しました。

これと並行して、コミッターのNoah Misch氏もClaude Opus 5でメインブランチのコードをスキャンしており、重鎮Tom Lane氏に至っては8月28日のクエリプランナ向けパッチのコミットメッセージに「初稿はClaude Opus 4.8で生成」と公に明記しました（もっとも同氏は極めて実務的な節度を保っており、外部から送られたAI一括生成のテストケース群については、恒久的なテスト実行時間のオーバーヘッドばかり増やして費用対効果が低いとしてきっぱり却下しています）。

8〜10件の大型機能を切り捨てて何を守り抜いたのか

例年の通常サイクルであれば、PostgreSQLがBetaフェーズに入った後にロールバックされる新機能はせいぜい1件程度です。ところが今年は8月末から9月中旬にかけてのわずか3週間で、リリース品質の最終防衛ラインを守るため、コアチームは前代未聞の終盤大量リバートに踏み切りました。集計の粒度によって 8〜10件の大型機能 が引き揚げられています（Snowflakeエンジニアリングチームの集計によれば、Beta開始から9月中旬までにブランチ上で累計53回ものrevertコミットが発生しました）。

• SQL/PGQ プロパティグラフクエリ（9月7日リバート）：今サイクル最大規模の目玉機能であり、単一のリバートコミットで 124ファイル・約1万6,000行のコード が一挙に削除されました。決定的な欠陥は依存オブジェクト削除時のロック不足にあり、根本修正にはシステムカタログ（catversion）の変更が不可欠でした。議論の中でTom Lane氏は「夕食を賭けてもいいが、このまま強引にv19で出荷すれば、v20まで直せないバグを必ず残すことになる」と断言しています。
• データチェックサムのオンライン有効化・無効化（9月16日リバート）：Claudeを用いた補助レビューにより、過去のクラスタクラッシュで残存した孤児リレーションファイルがあると pg_basebackup のバックアップ検証が失敗する問題が発覚しました。短期間での安全な解決策が見出せず、関連する30件のコミットごと撤回されました。
• UPDATE / DELETE ... FOR PORTION OF（9月15日リバート）：READ COMMITTED 分離レベルにおける並行ロストアップデートなどのエグゼキュータ欠陥に加え、14件の未解決課題が残っていたため、23件のコミットを撤回（PG 18で導入済みの WITHOUT OVERLAPS 制約には影響ありません）。
• その他に撤回または部分縮小された機能：ALTER TABLE ... MERGE / SPLIT PARTITIONS によるパーティション統合・分割、pg_get_role_ddl() などのクラスタレベルDDL生成関数（後続12コミットを撤回）、非デフォルトの等価性セマンティクスと衝突する GROUP BY ALL、pg_dumpall の非プレーンテキスト出力、照合順序固有のケースフォールディング、および CREATE SCHEMA サブコマンド拡張などが含まれます。ここでコミュニティによくある誤解を1つ訂正しておくと、外部キー検査の高速化は全面撤回されたわけではありません。コミッターのAmit Langote氏が9月10日に取り除いたのはサブトランザクションと競合しやすい「バッチバッファリング層（batching layer）」だけであり、単一行ファストパス（per-row fast path）は無事にRC 1へ残されています。

公平を期すなら、この大量ロールバックの責任を100%外部のLLMだけに押し付けることはできません。Christophe Pettus氏とLayerbaseがGitのタイムスタンプを精査して指摘した「コインの裏側」もあります。今年は3月10日から4月8日の「フリーズの崖（freeze cliff）」直前の最後の5週間に、低レイヤの仕組みと深く結合する大型機能が8件も駆け込みで集中的にマージされており、REPACK (CONCURRENTLY) に至ってはフリーズのわずか40時間前に3つの既知の設計上の穴を抱えたまま滑り込んでいました。言い換えれば、フリーズ直前の駆け込みラッシュが高複雑度のアーキテクチャ負債を溜め込み、そこへLLM脆弱性ストームが外からは初夏のレビュー人員を吸い尽くし、内からは設計上の欠陥を急速に暴き立てた——この2つの力が正面衝突したことで、旧時代の速度感で設計された夏のテストカレンダーが完全に突き破られたのです。

朗報なのは、この痛みを伴う「安定性優先の決断」を経てもなお、PostgreSQL 19 RC 1公式リリースノートに生き残った機能群の実用価値が極めて高いことです。

• カーネルネイティブの REPACK と非ブロッキングな REPACK (CONCURRENTLY)：対象範囲を意図的に絞り込むこと（クラスタ全体で同時実行を単一プロセスに制限、heapテーブル限定、トランザクションブロック内での ANALYZE 付き実行を禁止）で厳しい審査を生き延び、DBAにとって長年の定番だったサードパーティ拡張 pg_repack からの卒業がついに現実味を帯びてきました。
• 公式クエリプラン制御拡張 pg_plan_advice と pg_stash_advice：SQL文を書き換えることなく、結合順序やスキャン方式、パラレル実行戦略をきめ細かく制御できます。
• レプリケーションと高可用性の長年の課題解消：シーケンス値の論理レプリケーション（Logical replication of sequences）、wal_level = replica のまま再起動なしで論理レプリケーションを開始できる機能、さらにスタンバイ側で読み書き一貫性を保証するネイティブ WAIT コマンドが揃いました。
• 運用・パフォーマンス面の強化：新しい優先度スコアリングスケジューラを備えたパラレル自動バキューム（Parallel autovacuum）、単一行ファストパスによる外部キー検査高速化、INSERT ... ON CONFLICT DO SELECT、COPY TO (FORMAT json)、そして本番運用の実態に即した2つのデフォルトパラメータ変更——jit のデフォルト無効化（off へ変更）と、コンパイル時サポートがある環境での default_toast_compression のデフォルト lz4 化——が含まれています。

5. AIが無限に次のバグを掘り起こす時代に「出荷可能」とは何か

PostgreSQL 19の今回の延期は、おそらくあらゆる大規模ミドルウェア・基盤ソフトウェアが「AI監査時代」へ足を踏み入れる最初の号砲にすぎません。

来年の二の舞を避けるため、PostgreSQLコミュニティ内部ではすでに極めて実務的なプロセス改革案がいくつもテーブルに載せられています。RMTメンバーのNathan Bossart氏は、2027年から定例マイナーリリースの頻度を従来の年4回から年6〜8回（6〜8週間に1回）へと引き上げ、小刻みな出荷によって1回あたり数十件のCVEを溜め込むリグレッションリスクを分散する案を提示しました。またPeter Eisentraut氏は、LLMを活用したファジングを機能マージ前の段階へ前倒しすることを呼びかけています。PostgreSQLは「あらゆる機能が直交的に組み合わせ可能であること」（たとえばドメイン型を入れ子にした複合型に、パーティションテーブルの変則的なアタッチ・デタッチと SECURITY DEFINER トリガを重ねるような構成）を美学としており、その組み合わせ爆発はもはや人間の脳では網羅しきれません。同時にコミュニティでは、メインブランチに「実験的機能（Experimental status）」という段階を設ける案も議論されており、4月8日のフリーズの崖を前に複雑な機能へ「一発で5年間の互換性を約束するか、丸1年差し戻されるか」の二者択一を迫らない仕組みが模索されています。

視野を横に広げれば、エンジニアリングされた「防御側AI」によって人間のメンテナのボトルネックを緩和する先行事例も出始めています。Phoronixの10月初旬の報道によると、GoogleのエンジニアがLinuxカーネルコミュニティ向けに構築したAIコードレビューシステム Sashiko は、すでに累計 19万1,000件以上のカーネルパッチ をレビューし、463件のLinuxカーネルCVE に関連する修正で引用され、一部サブシステムのメンテナの一次レビュー時間を60〜70%削減しています。

しかし、ツールやスケジュール以上に答えを出すのが難しいのは、Robert Haas氏が記事の結びで投げかけた次の問いかけです。「40年間にわたって人間が見つけられなかったものの、LLMなら確実に掘り起こせるバグの山を抱えているとしたら、私たちは一体どうやって追いつけばいいのだろうか。そしてPostgreSQLはどうやってイノベーションを続ければいいのだろうか。今のところ、私に答えはない。」

過去数十年間、基盤ソフトウェアがスケジュール通りにリリースできていた背景には、一種の自然な速度バランスがありました。「現時点で既知のブロッカー級バグがなければリリースに十分な品質とみなし、残りのロングテールなエッジケースは時間をかけて少しずつ炙り出す」という暗黙の前提です。ところが、機械がほぼ無限の計算資源を手にして40年分の既存コードのあらゆる極端な分岐を総当たりできるようになった瞬間、バグの発見速度は人間の修正帯域を完全に振り切ってしまいました。Hacker Newsや各国の技術コミュニティの議論では、すでに多くの第一線のアーキテクチャ設計者が「リリース麻痺（Release Paralysis）」を懸念し始めています。AIが古いシステムから「10年間一度も踏まれなかった実在のエッジケースバグ」を毎日10件ずつ新たに引っ張り出してくる世界で、一体誰が「ここまで直したから手を止めて出荷しよう」と決断できるのでしょうか。

この問いに、短期間で模範解答が見つかることはないでしょう。それでも少なくとも2026年のこの秋、「1年の間に急に賢くなったわけではない」31人のデータベースの番人たちは、最も素朴で、かつ最も信頼に足る選択を示してくれました。不安を抱えた新機能を無理に押し込まず、10年続いたカレンダー上の儀式にも固執せず、たとえスケジュールを遅らせて延長戦に入ってでも、ユーザの手元に届けるデータの最終防衛ラインだけは決して譲らないという選択です。

---

参考資料・出典

1. PostgreSQL Global Development Group: PostgreSQL 19 RC 1 Released!（11月12日のRC 2および11月19日のGA予定を確定、2026-10-15）
2. Jonathan S. Katz (pgsql-hackers): Updated PostgreSQL RC / GA dates（3度にわたるスケジュール調整メールのアーカイブ、2026-10-10）
3. Robert Haas (Neon Blog): Postgres 19 is late, and it's AI's fault — LLMs are finding bugs faster than committers can fix them（Gitブランチ別コミット数 >60% / >74% 増加の元統計記事、2026-10-21）
4. Peter Eisentraut: The reverts will continue until morale improves（8〜10件の機能リバートと「実効的な品質ハードルの事後的な引き上げ」に関する考察原文、2026-10-09）
5. Robert Haas (pgsql-hackers): scary patch contest（Claudeを用いたフィーチャーフリーズ後の6大高リスクパッチセット監査メール原文、2026-08-25）
6. PostgreSQL Global Development Group: PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released!（単一リリースでの28件のCVE修正および18.5スキップの説明、2026-08-13）
7. PostgreSQL Documentation: Appendix E.1. Release 18.6 & Security Information（公式セキュリティ脆弱性一覧およびAIセキュリティチームの謝辞リスト）
8. PostgreSQL Security Advisory: CVE-2026-2005 — pgcrypto heap buffer overflow & CSO Online 詳細報道（2005年混入・20年以上潜伏したコード脆弱性の検証）
9. PostgreSQL Global Development Group: PostgreSQL 19 Beta 4 Released! & Release 19 Documentation（リバート一覧およびRC 1に残された機能の公式説明）
10. Christophe Pettus (The Build): 19th Nervous Breakdown（フィーチャーフリーズの崖の振り返りと2027年からの高頻度マイナーリリース提案の記録、2026-09-15）
11. Layerbase: When Will Postgres 19 Be Released?（アップストリームのリバートコミットハッシュおよびスケジュール時系列の検証、2026-10-15）
12. LWN.net: PostgreSQL 19's "scary patch contest" & Haas: Postgres 19 is late, and it's AI's fault（2026-09-10 / 2026-10-30）
13. Phoronix: AI Code Review System Has Reviewed 191k+ Linux Patches, Cited On 463 Kernel CVEs & AI-Generated Bug Reports "DoS Attack"（2026-08-25 / 2026-10-08）