PostgreSQL 19 推迟发布：AI 代码审查把“五年后的 Bug”提前翻了出来
PostgreSQL 19 从 10 月 29 日推迟到 11 月 19 日，并额外增加一个 RC2 候选版本。Beta 阶段撤回了 8–10 项重要功能，远超以往一个版本通常只回滚一项的水平。核心提交者 Peter Eisentraut 解释，问题并非出在“AI 写代码”，而是越来越强的 LLM 代码审查和模糊测试把过去要花五年才逐渐暴露的边缘缺陷集中翻了出来，短期内反而拖慢了发布节奏。
一次不寻常的发布推迟
PostgreSQL 团队近日宣布，原计划 10 月 29 日发布的 PostgreSQL 19 推迟到 11 月 19 日。在此之前还会多出一个 RC2 候选版本，于 11 月 12 日发布。官方给出的理由是，近期合入各维护分支的修复数量较多，希望先用 RC2 让社区验证一遍，再走正式发布流程。
发布日期调整本身不算罕见，真正不寻常的是功能撤回的规模。进入 Beta 阶段后，大约 8–10 项重要功能从 PostgreSQL 19 中被撤下，其中部分功能是在相当靠后的阶段才被移除。按惯例，一个 PostgreSQL 大版本周期里出现一项重要功能回滚并不奇怪，但一次撤回接近十项，已经明显超出常规。
PostgreSQL 核心提交者、EDB（PostgreSQL 主要商业支持公司）副总裁 Peter Eisentraut 随后专门撰文解释了这次异常。他把关键变量指向了一个正在快速成熟的东西：大模型辅助的代码审查与模糊测试。
不是“AI 写烂代码”，而是“AI 查得太狠”
一个很容易出现的猜测是：开发者用 Claude、Codex 等模型大量生成 PostgreSQL 代码，质量不过关，于是在 Beta 阶段集中爆雷。Peter Eisentraut 明确否定了这种归因。
他指出，大多数受影响并最终被撤回的功能，早在 LLM 辅助编程和代码审查成熟之前就已经完成。换句话说，这些代码是按传统流程写出来的；真正发生变化的是后来介入的 AI 审查工具，它们开始重新检查此前已经存在的代码。
Peter 把发现的问题大致分成两类。第一类确实比较严重：一些被撤回的功能存在架构层面的缺陷，在 Beta 阶段短时间内很难彻底修正。除此之外，还有大量长尾问题——单独看并不严重，只在特定边缘条件下才会触发。
放在过去，这类问题往往不会在发布前被发现。PostgreSQL 会照常发布，然后在未来几年里随着真实用户撞上各种罕见组合，再一点点打补丁修复。Peter 估计，其中不少问题原本可能要在接下来五年里才逐渐浮现。
LLM 改变了这个过程。借助 AI 辅助代码审查，过去分散在数年时间里的边缘缺陷，现在可能在几天或几周内被集中扫出来。
一个直观的例子：开发者突然面对大约 40 份缺陷报告。即便每个问题平均只需要改 3 行代码，处理每一个问题仍然有固定成本——理解上下文、复现、确认、写测试。代码本身可能只改几分钟，但几十个问题叠加起来，人类的时间很快就被耗尽。
这带来一个相当反直觉的结果：AI 提高了软件质量，却可能在短期内降低软件发布速度。Peter 把这种现象概括为“有效质量门槛被抬高了”。这些功能当初开发和提交时，行业还没有今天这样的 LLM 审查能力；等到 PostgreSQL 19 准备发布时，新工具已经能发现过去难以发现的问题。原本可能符合发布标准的代码，在新的审查能力下突然“不够好了”。
数据库为什么特别容易被“查”出问题
数据库尤其容易遭遇这种情况。
PostgreSQL 的一个重要特点是，开发者期待不同功能能够自由组合。一个 SQL 功能不仅要在最普通的情况下运行，还可能被放进 domain、复合类型、分区表、视图、安全定义函数（security definer）、触发器等各种环境里，而且这些能力还能继续互相嵌套。
Peter 举了一个组合例子：
撤回的不只是 AI 的“锅”
不过 Peter 也强调，AI 并非这轮大规模撤回的唯一原因。部分代码本身的质量和架构设计确实存在问题。今年 PostgreSQL 社区还经历了一轮密集的安全问题处理，大量资深开发者从 4 月到 8 月都在忙着修漏洞，原本应放在 Beta 前期进行的额外评审和测试因此被挤掉。等这些人重新投入 PostgreSQL 19 时，许多问题已经到了发布周期的后段才暴露出来。此外，PostgreSQL 自身不断增长的复杂性也是根本原因之一。
这些问题叠加在一起，最终迫使社区做出相当保守的决定。按统计方式不同，大约有 8 到 10 项重要功能已从 PostgreSQL 19 分支撤回，其中不少预计会在修正后重新进入 PostgreSQL 20。代表性的例子是 SQL/PGQ：它用于按照 SQL 标准查询由节点和边组成的属性图数据，但由于仍有未解决的问题，最终没能进入 PostgreSQL 19。
有意思的是，社区此前一度认为 PostgreSQL 20 可能主要用于修 Bug、不会有太多新功能；现在情况反了过来——PostgreSQL 19 撤下的这批功能，反而让 PostgreSQL 20 拥有了一批接近完成的候选特性。
当然，PostgreSQL 19 并不会因此变成“小版本”。Peter 提到，它仍将包含 REPACK CONCURRENTLY（在线重整表）、序列的逻辑复制，以及通过 pg_plan_advice 实现的查询规划器提示等重要能力。经历这轮额外审查后，他反而预计 PostgreSQL 19 会成为一个更稳健的版本。
发布节奏也已调整：RC1 按计划于 10 月 15 日推进，但正式版从原定的 10 月 29 日推迟到 11 月 19 日。发布团队还新增了 11 月 12 日的 RC2，让近期积累的大量修复再走一轮验证。官方把今年称为一个“不寻常的大版本发布周期”，并强调最终目标仍是保证 PostgreSQL 的稳定性和可靠性。
瓶颈从“发现 Bug”转向“给 Bug 分类”
这件事随后在开发者社区迅速发酵。不少开发者认为，软件开发的新瓶颈可能正在从“发现 Bug”转移到“给 Bug 分类”。
“这种情况不会很快消失，下一步真正需要解决的是如何对 AI 找出来的问题进行分类，只把最严重的问题优先送到人工审查。”另一些开发者指出，当找漏洞和构造异常输入的成本突然下降之后，“发现问题”和“修复问题”的速度已经不再匹配。以前安全研究者找到一个复杂缺陷可能需要几天甚至几周，而 AI 可以同时探索大量路径，人类维护者却仍然只能一个一个确认。
另一派开发者则担心，AI 会造成“真假 Bug 泛滥”。
有开发者表示，自己的经验是 AI 会报告大量从局部代码看起来合理、放到整个系统语境中却并不成立的问题。如果开发团队机械地修复每一个 AI 建议，最终可能得到一个过度设计、效率更差的系统。真正费时间的地方在于，人类必须逐项判断：这究竟是真 Bug、极端但可以接受的边缘情况，还是纯粹的误报。
一名从事数据工程的开发者称，在其内部的 AI 代码审查系统中，即便模型能够访问代码仓库、Confluence 和 JIRA 等上下文，大约也只有八分之一的报告最终被判定为有效；对于更通用的审查机器人，这个比例甚至可能更低。另一名熟悉静态分析工具的开发者则表示，大量误报一直是自动化分析长期存在的问题，一旦积累到十万级缺陷报告，要求人工做到 100% 确认几乎不现实。
误报再多，也有人不愿放弃 AI 审查
不过，也有用户用自己的经历证明：即便对误报不满，仍然不愿意放弃 AI 审查，因为它确实能把隐藏多年的技术债翻出来。他们曾让 AI 对一个已稳定运行约 10 年的客户系统中的脚本、任务和配置做集中代码审查，最终找出 39 个问题，其中 30 个被确认为真实 Bug，只不过此前从未被触发。
类似情况并不只发生在 PostgreSQL 这样的开源项目里。一些闭源软件中，开发多年的功能同样开始因为大模型新发现的问题而无法按原计划发布。过去的做法可能是先上线、再在未来版本逐步打补丁；但一旦开发团队已经明确知道某个 Bug 或理论漏洞存在，继续把它带进正式版本，在安全和责任层面都会越来越难解释。
有开发者指出，数据库这类复杂基础软件中的很多问题，并不是把 Bug 报告重新扔给大模型、再点一下“自动修复”就能解决的。一些缺陷实际上对应的是架构和产品语义上的取舍：某一种行为在场景 A 下可能是 Bug，在场景 B 下可能是合理设计，换到场景 C 又可能意味着一年前的基础设计本身需要重做。AI 可以非常便宜地把这种矛盾找出来，但决定“正确行为究竟是什么”，依然需要经验丰富的维护者。
下一个难题：究竟修到什么程度才允许发布
甚至已经有人开始担心另一种极端：“发布瘫痪”。如果 AI 可以不断从任何复杂代码库里挖出新的边缘问题，那么理论上永远存在下一个 Bug。项目究竟应该修到什么程度才允许发布，未来可能成为比“AI 能找到多少 Bug”更困难的问题。
有开发者建议，与其追求在单个版本里消灭所有 AI 找出的缺陷，不如把它们系统化登记、分级，纳入后续开发路线。否则，没有任何大型软件能够达到真正意义上的“零缺陷”。
真正稀缺的是判断力
Claude Code、Codex 这类工具的编码能力越来越强之后，让 AI 写代码已经不成问题。PostgreSQL 19 的这次风波进一步说明：当 AI 也能大规模审查、测试甚至“攻击”代码时，“发现问题”同样不再是瓶颈。
接下来真正稀缺的，可能变成了人的判断力：
- 哪些问题必须修，哪些可以接受；
- 一个三行代码就能修好的边缘缺陷，值不值得为它推迟一个重要功能；
- AI 列出的几十个问题里，哪几个其实指向架构本身需要重新设计；
- 当机器可以无休止地寻找异常时，一款软件究竟要达到什么程度，才算“足够好，可以发布”。
关键要点
- AI 让“写代码”和“找问题”都不再稀缺，稀缺的是取舍与决策。
- 修复成本与发布节奏之间如何平衡，需要人来定标准。
- 当审查可以无限进行，“足够好”的发布门槛必须由人明确划出。
参考链接：
https://www.theregister.com/databases/2026/10/16/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix/5303471
https://www.postgresql.org/message-id/f161fbb7-e193-42eb-bec7-4cfc1af74a50%40postgresql.org
https://peter.eisentraut.org/blog/2026/10/09/the-reverts-will-continue-until-morale-improves
https://www.postgresql.org/message-id/646368.1787697184%40sss.pgh.pa.us
https://www.postgresql.org/message-id/CAN4CZFP0qF6YH7dY9qufFuGf-wZ0%2BpKx3OXKDw8kN_AGOu4C1w%40mail.gmail.com
https://news.ycombinator.com/item?id=50119991
https://www.reddit.com/r/technology/comments/1x9h7e1/postgres_19_delayed_after_ai_reviewers_find_more