PostgreSQL 19 延期拆解：back-patch 提交暴涨 61%，LLM 审查翻出三十年存量 bug

2026 年 10 月 15 日，PostgreSQL 官网开发者页面挂出横幅：PostgreSQL 19 RC 1 发布。按这个项目过去十年的节奏，正式版（GA）应该在 9 月中旬到 10 月中旬之间落地，PostgreSQL 17 是 2024 年 9 月 26 日，PostgreSQL 18 是 2025 年 9 月 25 日。这一次，据 The Register 报道，社区给出的预期是 11 月 19 日前后。与延期一起发生的还有一件更少见的事：8 到 10 个已经开发完成的重量级特性，在 beta 后期被整体回退，推迟到 PostgreSQL 20。

两位 PostgreSQL committer 先后写了长文解释这件事。Peter Eisentraut（EDB 副总裁、参与 PostgreSQL 开发二十五年的核心 committer）在 10 月 9 日发表《The reverts will continue until morale improves》；Robert Haas 在 10 月 21 日于 Neon 博客发表《Postgres 19 is late, and it's AI's fault》，用 git 提交数据把原因量化了。两篇文章合起来给出一个完整的答案：LLM 辅助的代码审查和测试，把这个有四十年历史的代码库里人类一直找不到的存量 bug 成批翻了出来，而人工修复的带宽没有同比例增长。

back-patch 提交一年涨了 61%

Haas 的统计窗口是每年的 4 月 8 日（特性冻结日）到 9 月 25 日：

统计项	2025 年窗口	2026 年窗口	变化
master 分支总提交	1037	1443	+39.1%
其中回填到当年 stable 分支	724（REL_18_STABLE）	1169（REL_19_STABLE）	+61.5%
仅进入 master 的提交	313	274	-12.5%
回填到上一代 stable 分支	248（REL_17_STABLE）	433（REL_18_STABLE）	+74.6%

表中第三行由前两行相减得出。三个方向放在一起看：新特性类提交在降，修 bug 类提交在暴涨。PostgreSQL 的维护惯例是所有 bug 修复都要回填（back-patch）到每一个仍受支持的旧版本分支，所以回填数近似等于「被认定需要修的 bug 数」。一年之内涨 61.5%，回填到上一代分支的部分涨 74.6%，Haas 原文的表述是「超过 74%」。

Haas 不认为这是 committer 在 2026 年犯了更多的错。他的判断是：committer 的保守程度与前几年相当，变化来自另一侧，互联网上大量的人正在用 LLM 寻找 PostgreSQL 的 bug，找到就报给社区，committer 一直忙于修复。回填量暴涨的另一面，是全网的 LLM 在给这个项目做免费的全量代码审查。

四十份缺陷报告，每份平均三行修复

Eisentraut 的文章补上了机制细节。被回退的特性里，一部分确实存在架构级缺陷，beta 期间来不及修；但还有一条长尾，由大量相对无害的边界情况问题组成。这类问题放在以前，会在发布后五年内被逐个发现、逐个修掉，用户几乎无感。LLM 辅助审查把它们在 beta 期间一次性全翻了出来。

他给过一个量化描述：盯着一份四十条左右的缺陷报告清单，平均每条修复只要三行代码，但每一条都有固定处理开销，读报告、复现、评审、提交、回填，时间就是这样耗尽的。

时间差是整件事的关键：这批被回退的特性大多写于 LLM 审查能力可用之前，beta 期审查启动时工具已经变强，等效的质量门槛在代码写完之后被抬高了。Eisentraut 还专门澄清，这与「vibe coding」无关，受影响的代码成文时这种方式还不存在。

被回退的三个大特性

Haas 列出了三个在 8 月 27 日到 9 月 15 日之间回退的大件：

SQL Property Graph Queries（SQL/PGQ）：SQL:2023 标准引入的图查询语法，在关系表上表达节点和边的遍历。实现暴露出未解决的问题，整体移除。Tom Lane 在讨论中的表态被 The Register 引用：他赌一顿晚饭，如果 v19 硬发，发布后一定会出现直到 v20 才能修的 bug。
ALTER TABLE MERGE PARTITION / SPLIT PARTITION：分区合并与拆分，DBA 等了多年的运维特性。
UPDATE/DELETE FOR PORTION OF：SQL 标准的时态特性，只对行在指定时间段内的部分做更新或删除。

一个发布周期回退一两个特性是常态，一次回退 8 到 10 个、且多数拖到 beta 后期，是 PostgreSQL 近年少有的情况。

人工枚举不完的组合空间

Eisentraut 用一个例子解释了这类 bug 以前为什么发现不了。一个 SQL 层的新语法，要验证它在各种上下文里是否都成立：域类型（domain）下能用吗？组合类型上的域呢？域的字段本身又是域？带 NOT NULL 约束？列被删掉又加回来？位于一个被 detach 又以不同列序 attach 回来的分区里？在一个被 security-definer 函数从触发器调用的视图里？他说，没有人能手工测完这些组合，甚至没有人能把这些测试用例枚举全，而 LLM 辅助的模糊测试可以很快在其中找到问题。

PostgreSQL 的吸引力之一是「everything works with everything」，任何特性组合都应当成立。这个承诺在 LLM 审查时代意味着每个新特性都要面对组合空间的完整检验。Eisentraut 的判断是，这类测试必须成为今后特性开发流程的一部分，同时内部接口要做得更健壮，压缩上下文组合带来的交互面。

另一个被两篇文章共同提到的时间因素：2026 年 4 月到 8 月的安全漏洞风暴（Vulnpocalypse）占用了资深开发者大量精力，beta 期本该做的补充审查被压缩，8 月才重新捡起来。这也是大量问题被发现得如此晚、回退来得如此集中的原因之一。社区的应对流程也在讨论中，比如给合入主干的特性引入「experimental」实验状态，让新特性先在主线里成熟。

PG 19 还剩下什么

延期归延期，Eisentraut 对 PostgreSQL 19 的成色判断是积极的。他点名的三个保留特性：

REPACK CONCURRENTLY：在线回收磁盘空间，不再需要 VACUUM FULL 的排他表锁，对大表的磁盘回收是实打实的改进；
序列（sequence）的逻辑复制：这个特性本身曾在更早的周期被回退过，这次留了下来；
pg_plan_advice：执行计划提示。

他还给了一个判断：经过这一轮高强度审查，PostgreSQL 19 会是一个非常健壮的版本。被回退的特性大部分会先进入 PostgreSQL 20。几个月前社区还预计 PG 20 会是没有新特性、只修 bug 的版本，现在它大概率要继承 PG 19 退回的这一批，Eisentraut 的原话是「几个 80% 就绪的特性，只差剩下的 80%」。

对使用者的实际影响

正在做升级规划的团队，时间表要按 11 月 19 日之后重排；正式版发布后，每季度一次的 minor 版本节奏不受影响。生产环境没有必要碰 beta，但如果条件允许，RC 1 是开始新版兼容性验证的合理起点，源码和发布说明都在官网开发者页面。

对维护大型代码库的工程团队，这件事的参考价值在流程侧：当发现 bug 的成本趋近于零，瓶颈就移到了验证和评审。Hacker News 的讨论里，Simon Willison 提出了对应的反面：搜索类任务最常见的错误是遗漏，而验证「该找到的是否都找到了」同样困难。Haas 在文末把他那代人面对的问题写得很清楚：四十年积累的、人类没找到而 LLM 找得到的 bug，怎么追得上，以及 PostgreSQL 如何继续创新。他的回答是，包括他在内的很多人都在拼命想办法，目前没有定论。

来源：