打破十年秋季發版鐵律 PostgreSQL 19 首次延期與 LLM 漏洞風暴下的人類審查極限

從 2016 年的 PostgreSQL 9.6 到去年的 PostgreSQL 18，這個全球最受信賴的開源關聯式數據庫連續 10 個大版本從未失約過「9 月中旬至 10 月中旬」的秋季發版窗口。但在今年，PostgreSQL 19 罕見地破例了——歷經增發 Beta 4 與 RC 2 兩次「加賽」，官方已將正式版（GA）計劃日期推遲至 2026 年 11 月 19 日，並在測試後期集中砍掉了 8 到 10 項已經合入的重大新功能。

拖慢發版節奏的並不是外界第一反應猜測的「AI 寫出了太多劣質程式碼」，恰恰相反，是全網安全團隊與核心維護者手裏的 LLM 找 Bug 太快了。當受支援分支的年度真實安全漏洞（CVE）暴漲逾 5 倍、向已發佈舊生產分支跨代回溯的修補程式一年激增 74.6%，全球僅有的 31 名活躍提交者第一次正面撞上了人類審查與回歸驗證的吞吐極限。

一、十年發版鐵律破功與兩次罕見「加賽」

三次退守的秋季日曆

如果你平時負責維護生產環境的 PostgreSQL 叢集，很大機會早已習慣了它像瑞士鐘錶一樣的年度節奏。翻開官方版本生命週期紀錄，過去十年連續 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 日才發佈，起步就晚了將近一個月。

進入 9 月後，發佈協調人、核心團隊成員 Jonathan S. Katz 在 pgsql-hackers 郵件列表裏連發三封排期通知，清晰記錄了社群試圖守住十年慣例卻最終退守的全過程：

• 9 月 3 日（增發 Beta 4）：宣佈在 9 月 24 日增發非常規的第四個測試版 Beta 4（常規週期通常只需 3 個 Beta）。他在電郵裏直言，此舉是為了應對「近期湧入且耗費額外時間處理的大量問題報告」，並在註腳裏直接貼出了單次修掉 28 個 CVE 的 18.6 發行說明作為例證。當時團隊的目標仍是力保 10 月底前發版。
• 9 月 28 日（試圖趕及 10 月底）：Beta 4 發完四天後，團隊給出了一份緊湊的衝刺排期——定於 10 月 15 日發 RC 1，不設 RC 2，力爭在 10 月 29 日直接推出正式版，趕在 11 月例行小版本更新前留出兩週緩衝。
• 10 月 10 日（增發 RC 2，正式推遲至 11 月）：距離 RC 1 只剩五天時，發佈團隊終於決定不再硬撐，宣佈在 11 月 12 日增發 RC 2（與 Q4 季度例行小版本同日發佈），先把各舊維護分支新累積的一大批修復合入驗證一週，再於 11 月 19 日發佈 PostgreSQL 19 正式版。10 月 15 日的 RC 1 官方公告正式確認了這一日程，同時保留了「若發現阻塞問題仍可能繼續延期或增發候選版本」的前提。

61.5% 與 74.6% 的兩組 Git 提交賬本

為甚麼舊分支的修補程式會多到把新大版本硬生生擠出十月？

10 月 21 日，資深提交者 Robert Haas（現任職於 Databricks）在 Neon 網誌發表了一篇標題毫不留情的復盤長文——《Postgres 19 遲到了，這得怪 AI》（10 月 30 日同步至個人網誌後引發全網熱議）。他在文裏列出了 2025 年與 2026 年完全同口徑時間窗口（每年 4 月 8 日功能凍結至 9 月 25 日）的官方 Git 儲存庫提交賬本。

這兩天不少二手資訊把「挖出陳年舊 Bug」和「回溯修補程式暴增 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 新功能修補/回滾及主幹同步回溯（即「逾 60%」口徑）
跨代回溯至已發佈舊生產分支提交	248 次（入 REL_17_STABLE）	433 次（入 REL_18_STABLE）	+74.60%	真正衡量影響既有線上版本的歷史 Bug 修復（一年暴漲近四分之三）

賬面非常清楚：提交者們今年寫新功能的程式碼量不僅沒升，反而還少了 12.5%；真正把儲存庫撐爆的，是從主幹往在研分支回溯的 1,169 次提交（+61.46%），尤其是那些必須跨代往至少一個已發佈歷史生產版本套用修補程式的陳年缺陷修復，單年猛增了 74.60%。

並不是「Vibe Coding」惹的禍

看到「AI 導致數據庫延期」和「大量功能被回滾」，很多人的第一反應是：是不是這班開發者開始用 AI「憑感覺寫程式（Vibe Coding）」，把一堆半成品塞進了核心？

另一位核心團隊成員兼提交者、EDB 副總裁 Peter Eisentraut（他本人就是今年多項被回滾功能的作者或提交者）在 10 月 9 日發表的《回滾還將繼續，直到士氣改善》中直接否定了這個猜測。

他指出，今年受影響被回滾的絕大部分功能，早在 LLM 程式碼審查成熟之前就已經寫完提交了；提交者合入程式碼時的審慎尺度與往年也沒有分別。真正發生劇變的是另一頭——「有效質素門檻是在功能編寫並提交之後，被事後抬高了。」

在過去，一套複雜數據庫功能的邊緣組合缺陷，往往會在正式發版後的 5 年時間裏隨着不同用戶的極端生產負載零星浮出水面，社群可以按部就班地一點點修補。但今年，全網研究者和開發者拿着前沿大模型對着原始碼做輔助審查與模糊測試，硬是把原本分散在五年週期裏的長尾隱患，一次性摺疊並引爆在這一個夏天。

二、2026 漏洞風暴與潛伏 20 年的程式碼死角

不是垃圾報告轟炸，而是高危真洞洪峰

今年開源界苦於「AI 垃圾報告（AI Slop）」已久。1 月底，cURL 因為 HackerOne 上的 AI 虛假漏洞報告泛濫、有效率跌破 5%，直接關停了漏洞賞金計劃；8 月下旬，QEMU 儲存庫更是遭單一帳號在不到 10 分鐘內傾瀉了 132 條未經核實的 AI 生成 UBSan 報錯，被 Red Hat 資深維護者公開定性為針對維護者心智頻寬的「阻斷服務攻擊（DoS）」。

因此在 Hacker News 的討論區裏，不少外部開發者一開始以為 PostgreSQL 也是被低質素的 AI 幻覺報告拖垮的。但翻開 PGDG 官方的安全漏洞總表就會發現，PostgreSQL 遭遇的根本不是假報告騷擾，而是一場貨真價實的高訊噪比「漏洞風暴（Vulnpocalypse）」。

儘管官方並未披露私密安全電郵（security@postgresql.org）後台攔截了多少無效誤報，但僅看經過安全團隊嚴格復現、確認影響受支援分支（PG 14–18）並正式分配編號的真實 CVE 數量，曲線就已經徹底急劇攀升了：

• 2023 年全年：7 個 CVE
• 2024 年全年：7 個 CVE
• 2025 年全年：7 個 CVE
• 2026 年前三次例行更新（截至 8 月）：44 個 CVE（外加逾 235 個普通 Bug，11 月 12 日待發的第四批尚未計入）

連續三年穩如直線的「每年 7 個」，在 2026 年前三個季度直接飆升至 44 個，按年暴漲 528.6%（往年全年均值的 6.29 倍）。拆開今年這三次季度更新，壓迫感是一浪高過一浪的：2 月 12 日（18.2 批次）修了 5 個 CVE；5 月 14 日（18.4 批次）升至 11 個；到了 8 月 13 日（18.6 批次），單次集中修復了創紀錄的 28 個 CVE 和超過 110 個普通 Bug，其中約一半是 CVSS 8.8 級的堆緩衝區溢位、整數溢位、類型混淆或任意程式碼執行高危漏洞。

致謝欄裏的 AI 安全戰隊與「撞洞」奇觀

去讀今年這三次安全公告和 18.6 官方發行說明的致謝欄，簡直像在看全球前沿大模型與自動化漏洞引擎的實戰榜單：

• Claude & Anthropic Research：5 月聯合 Calif.io 報告了 hstore 二進制輸入堆疊溢位（CVE-2026-6479）；8 月聯合安全研究員 Ben Morris 一次性署名 3 項高危漏洞，包括 ltree 堆緩衝區溢位（CVE-2026-16239）、EXTRACT() 反解析超級管理員 SQL 注入（CVE-2026-15741）與角色列表反解析注入（CVE-2026-15742）。
• 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）、騰訊玄武實驗室 XlabAI 團隊聯合 Atuin 自動化漏洞挖掘引擎（CVE-2026-6475）、螞蟻 AntAISecurityLab（聯合復旦大學）以及 TrendAI ZDI 悉數在列。

當全世界的安全團隊同時拿頂級模型去掃描同一份擁有三四十年歷史的 C 語言程式碼庫時，誕生了兩個極具時代標誌性的現象。

第一個是二十年陳年死角被掀底。今年 2 月修復的高危漏洞 CVE-2026-2005（CVSS 8.8，允許密文提供方以數據庫作業系統用戶身份執行任意程式碼），由 Xint Code 團隊藉助 AI 審計發現。溯源 Git/CVS 歷史可以發現，這段存在堆緩衝區溢位的程式碼早在 2005 年就隨 pgcrypto 加密擴展模組合入了主庫，在無數生產環境裏潛伏了整整 20 多年，躲過了歷代人工審計和傳統 Fuzzing，直到今年才被大模型一眼看穿（同期 Xint Code 還在 MariaDB 裏挖出了一個 2004 年引入、潛伏 22 年的堆疊溢位漏洞 CVE-2026-21576）。

第二個是十幾家團隊同時「撞洞」。在傳統安全研究裏，兩個獨立團隊在同一個月撞上同一個深層漏洞就已經算是巧合；而在今年 5 月披露的 CVE-2026-6473（jsonb_populate_recordset 類型混淆導致任意程式碼執行）致謝名單裏，官方罕見地列出了 10 組獨立報告者；到了 8 月的 CVE-2026-14669，共同致謝名單更是刷新到了 11 組（OpenAI Codex Security 與螞蟻 AntAISecurityLab 都在其中）。大模型不僅壓低了挖洞門檻，還讓不同團隊在相近的推理路徑上批次收斂到了同一批歷史盲區。

三、31 名人類守門人的吞吐極限與三次回歸驚魂

為甚麼不能直接讓 AI 修補 AI 挖出來的洞

既然大模型這麼擅長找 Bug，為甚麼不直接讓它生成修補程式，甚至順手把程式碼審查也一併完成？

答案藏在「生成容錯率」和「核心背書責任」的巨大鴻溝裏。根據 PGDG 官方的提交者名錄，支撐起全球數百萬企業核心數據庫的 PostgreSQL 主程式碼庫，目前擁有直接 Git 推送權限的活躍提交者（Committer）加起來只有 31 個人。

這 31 個人的分工高度重疊：其中 20 人同時兼任 PostgreSQL Security Team 成員，必須在不公開細節的前提下驗證私密漏洞報告，並手動為 PG 14、15、16、17、18 五個受支援主版本編寫和適配回溯修補程式；而負責統籌今年大版本質素的發佈管理團隊（RMT）更是只有 3 個人（Nathan Bossart、Heikki Linnakangas、Melanie Plageman），前兩位本人還得在一線親自操刀編寫今年多宗高危 CVE 的修復程式碼。

Robert Haas 在復盤裏說了一句一針見血的實話：「LLM 可以起草修補程式，但這些修補程式並不總是正確的，也未必符合 PostgreSQL 的規範標準。它們仍然需要由人類來審查和提交，而這些人類在 2025 年到 2026 年之間並沒有變得更聰明。」

PGX 首席顧問 Christophe Pettus 在《19th Nervous Breakdown》裏記錄過一個絕佳的真實案例：今年測試期間，資深貢獻者 Thom Brown 用 Claude 成功定位到了新功能 REPACK 在邏輯解碼場景下會導致整個叢集崩潰的真實深層缺陷，Claude 也順手給出了兩處單行修復程式碼；結果原作者 Antonin Houska 審查時發現，AI 給的兩處修改裏有一處是錯的，直接合入反而會破壞底層狀態。

就算修補邏輯真的只有寥寥幾行，工程上的「剛性固定開銷（fixed overhead）」也省不掉。正如 Peter Eisentraut 算的那筆賬：當你面前突然擺着一份 40 條缺陷報告的清單，就算每條平均只需要改 3 行程式碼，從構造最小復現用例、在郵件列表裏往返討論邊界影響、補齊回歸測試，到手動跨越五六個歷史分支解決衝突並觀察跨平台建置農場（Buildfarm）結果，每一道工序都在實實在在地消耗這 31 個人的心智頻寬。

半年三次失手與高頻回溯引發的次生回歸

更棘手的是，在高壓之下往五個歷史生產分支高頻塞入幾百個安全與缺陷修補程式，已經在今年上半年對 PostgreSQL 引以為傲的小版本穩定性造成了肉眼可見的反噬：

1. 2 月計劃外緊急發版（18.3）：2 月 12 日剛發完包含 5 個 CVE 修復的 18.2 系列，僅隔 4 天，官方就因安全修補程式在多位元組文字處理中引發了 substring() 嚴重回歸，被迫宣佈計劃外更新，於 2 月 26 日緊急推出 18.3 / 17.9 / 16.13 / 15.17 / 14.22 救火。
2. 5 月引入從庫重放自死鎖：5 月 14 日發佈的 16.14 / 15.18 / 14.23（含 11 個 CVE 修復），在 PG 14–16 從庫追隨舊版本主庫進行 WAL 日誌重放時意外引入了自死鎖（self-deadlock）回歸，一直拖到 8 月才徹底修復。
3. 8 月罕見廢棄並跳號 18.5：8 月中旬在打包封版（wrap）18.5 之後、正式對外發佈前的最後關頭，團隊又抓出了新的回歸缺陷，被迫直接作廢 18.5 這個版本號，在 8 月 13 日跳號發佈了 18.6。

把上半年這三次驚魂串起來看，就能徹底理解發佈團隊在 10 月 10 日的選擇了。面對 11 月 12 日即將隨 Q4 例行更新一起落地的又一大批回溯修補程式，寧可打破連續十年的秋季發版紀錄、多發一個 RC 2 讓全網公開驗證一週，也絕不能讓未經充分壓力測試與驗證的大批底層改動直接混進 PostgreSQL 19 的首發正式版裏。

四、Claude 驅動的「高危修補程式審判」與斷臂保穩

一封引爆回滾潮的電郵

4 月到 8 月的「漏洞風暴」不僅考驗着舊分支，還抽走了資深提交者原本用來打磨 PG 19 新功能的黃金夏天。等大家在 8 月中旬好不容易從 28 個 CVE 的 18.6 發版裏喘一口氣、轉頭審視即將進入候選期的 PG 19 時，留給他們的修補窗口已經所剩無幾。

有趣的是，核心維護者們自己也拿起了大模型當手術刀。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 月中旬的三週內，為了保住發版底線，核心團隊掀起了一場史無前例的後期大回滾，按統計粒度不同共撤下了 8 至 10 項重大功能（據 Snowflake 工程團隊統計，Beta 啟動至 9 月中旬分支上累計出現了 53 次 revert 提交）：

• SQL/PGQ 屬性圖查詢（9 月 7 日回滾）：本週期體量最大的明星功能，單次撤銷提交直接刪掉了 124 個檔案、約 1.6 萬行程式碼。核心硬傷在於缺少依賴物件刪除鎖，且徹底修復必須改動系統表目錄（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 子命令擴展。順帶澄清一個社群常見誤傳：外鍵檢查提速並沒有被全盤砍掉——提交者 Amit Langote 在 9 月 10 日僅移除了容易與子事務衝突的「批次緩衝層（batching layer）」，而單行快速路徑（per-row fast path）已順利保留在 RC 1 中。

客觀地說，這波大回滾也不能把責任 100% 推給外部的 LLM。Christophe Pettus 和 Layerbase 在核查 Git 時間戳後指出了硬幣的另一面：在今年 3 月 10 日到 4 月 8 日「凍結懸崖（freeze cliff）」前的最後五週裏，社群密集突擊合入了 8 項深度耦合底層機制的大功能，REPACK (CONCURRENTLY) 甚至是在凍結前 40 小時帶着 3 條已知設計空洞壓線進場的。換句話說，凍結前的突擊衝刺埋下了高複雜度的架構存量，而 LLM 漏洞風暴既在外部抽乾了初夏的審查人力，又在內部加速揭穿了這些設計隱患，兩股力量撞在一起，徹底擊穿了按舊時代速率校準的夏季測試日曆。

好消息是，經過這輪近乎殘酷的「斷臂保穩」，留在 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)，以及兩項順應生產實踐的預設參數調整——預設關閉 jit（改為 off），並在編譯支援時將 default_toast_compression 預設切換為 lz4。

五、當 AI 能無限挖出下一個 Bug，甚麼才算「可以發版」

PostgreSQL 19 的這次推遲，很大機會只是所有大型基礎軟件邁入 AI 審計時代的第一聲驚雷。

為了避免明年重蹈覆轍，PostgreSQL 社群內部已經擺出了幾套非常務實的流程改革提案：RMT 成員 Nathan Bossart 提議從 2027 年起試行將例行小版本更新由每年 4 次增加至每年 6 至 8 次（每 6–8 週一次），用高頻小步快跑分攤單次累積幾十個 CVE 的回歸風險；Peter Eisentraut 則呼籲把 LLM 輔助模糊測試前置到功能合入之前，因為 PostgreSQL 崇尚「萬物皆可正交組合」（例如域嵌套複合類型、分區表異序拆裝疊加上安全定義者觸發器），靠人腦根本窮舉不完組合爆炸，同時社群也在探討引入主幹「實驗性功能（Experimental status）」分級機制，不必再逼着複雜功能在 4 月 8 日凍結懸崖前「要麼一步承諾五年兼容、要麼整年打回原形」。

橫向看去，用工程化的防守側 AI 來緩解人類維護者瓶頸也已經有了正面的先行樣本。據 Phoronix 10 月初報道，Google 工程師為 Linux 核心社群建構的 Sashiko AI 程式碼審查系統已累計審查逾 19.1 萬個核心修補程式，並在 463 個 Linux 核心 CVE 的關聯修復中被引用，幫部分子系統維護者省下了 60% 到 70% 的修補程式初審時間。

但比工具和排期更難回答的，其實是 Robert Haas 在文章結尾留下的那個追問：「既然我們累積了四十年來人類未能發現、但 LLM 卻完全有能力挖出的 Bug，我們究竟該如何追趕？PostgreSQL 又該如何繼續創新？眼下，我還沒有答案。」

過去幾十年裏，基礎軟件之所以能按時發版，很大程度上依賴一種天然的速率平衡——只要當前沒有已知的阻塞級缺陷，版本就是「足夠好」的，剩下的長尾邊緣問題留給時間慢慢暴露。可一旦機器擁有了近乎無限的算力去窮舉四十年存量程式碼裏的每一個極端分支，缺陷的發現速率就徹底脫離了人類的修復頻寬。在 Hacker News 與華語技術社群的討論裏，已經有不少一線架構師開始擔憂**「發佈癱瘓（Release Paralysis）」**——當 AI 每天都能在舊系統裏再揪出十個十年沒觸發過的真實邊緣 Bug 時，誰來拍板說「修到這裏就可以停下發版了」？

這道題短期內恐怕沒有標準答案。但至少在 2026 年的這個秋天，那 31 個「沒有在一年之間變得更聰明」的人類數據庫守門人，還是給出了最樸素也最讓人安心的選擇：不將就放行帶病上線的新功能，不迷信維持了十年的日曆儀式感，就算延期加賽，先把交到用戶手裏的數據底線守住。

---

參考與信源

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（三次排期調整電郵歸檔，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 輔助審計凍結後六大高危修補程式集原始電郵，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 深度報道（潛伏逾 20 年的 2005 年程式碼漏洞核實）
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）