PostgreSQL 19 打破十年釋出鐵律，LLM 漏洞挖掘風暴與 31 名提交者瓶頸解析

從 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 修復（一年暴漲近四分之三）

PostgreSQL 2025 與 2026 同口徑 Git 分支提交帳本對比資訊圖表

帳面非常清楚：提交者們今年寫新功能的程式碼量不僅沒漲，反而還少了 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 級的堆積緩衝區溢位、整數溢位、型別混淆或任意程式碼執行高風險漏洞。

2026 年 PostgreSQL 受支援分支真實高風險 CVE 暴漲逾 5 倍與 AI 稽核奇觀

致謝欄裡的 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 個人的心智頻寬。

半年三次翻車與高頻回溯引發的次生回歸

全網 LLM 漏洞挖掘與全球 31 名人類提交者審查瓶頸及半年三次回歸事故

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

2 月計畫外緊急釋出（18.3）：2 月 12 日剛釋出包含 5 個 CVE 修復的 18.2 系列，僅隔 4 天，官方就因安全補丁在多位元組文字處理中引發了 substring() 嚴重回歸，被迫宣布計畫外更新，於 2 月 26 日緊急推出 18.3 / 17.9 / 16.13 / 15.17 / 14.22 救火。
5 月引入從庫重放自死結：5 月 14 日釋出的 16.14 / 15.18 / 14.23（含 11 個 CVE 修復），在 PG 14–16 從庫追隨舊版本主庫進行 WAL 日誌重放時意外引入了自死結（self-deadlock）回歸，一直拖到 8 月才徹底修復。
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 官方發行說明裡的留存特性含金量依然極高：

PostgreSQL 19 晚近撤回的 8 至 10 項特性與 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 崇尚「萬物皆可正交組合」（例如網域巢狀複合型別、分區資料表異序拆裝疊加上 SECURITY DEFINER 觸發器），靠人腦根本窮舉不完組合爆炸，同時社群也在探討引入主幹「實驗性特性（Experimental status）」分級機制，不必再逼著複雜特性在 4 月 8 日凍結懸崖前「要嘛一步承諾五年相容、要嘛整年打回原形」。

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

AI 稽核時代 PostgreSQL 與大型開源基礎軟體的四項釋出治理新提案

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

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

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

PostgreSQL 19 打破十年秋季釋出鐵律，LLM 挖洞潮如何逼出首次延期與十項特性回滾

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

三次退守的秋季日曆

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

並不是「Vibe Coding」惹的禍

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

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

致謝欄裡的 AI 資安戰隊與「撞洞」奇觀

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

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

半年三次翻車與高頻回溯引發的次生回歸

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

一封引爆回滾潮的郵件

砍掉 8–10 項重大特性，留住了什麼

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

參考與資料來源

Tintdex 終端機配色工作台，2037 套主題線上預覽、調色與多端設定匯出

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

三次退守的秋季日曆

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

並不是「Vibe Coding」惹的禍

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

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

致謝欄裡的 AI 資安戰隊與「撞洞」奇觀

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

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

半年三次翻車與高頻回溯引發的次生回歸

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

一封引爆回滾潮的郵件

砍掉 8–10 項重大特性，留住了什麼

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

參考與資料來源

相關文章

Tintdex 終端機配色工作台，2037 套主題線上預覽、調色與多端設定匯出