PostgreSQL 19 发不出来？AI“找茬”太快，人类修Bug的速度跟不上了

PostgreSQL 19 的发布进程遭遇了罕见阻碍。团队宣布，原定于 10 月 29 日推出的正式版将延至 11 月 19 日。在此之前，项目会额外增加一个 RC2 候选版，计划在 11 月 12 日发布。官方解释称，近期各维护分支引入了大量修复，因此希望借助 RC2 让社区先行验证这些改动，再推进正式发布。

与此同时，自 Beta 阶段启动后，大约有 8 到 10 项关键功能被从 PostgreSQL 19 中移除，其中部分功能是在较晚的阶段才被剔除。通常来说，一个 PostgreSQL 大版本周期内出现一次重要功能回滚并不稀奇，但一次性撤回近 10 项，已明显超出常规范围。

PostgreSQL 核心提交者、EDB 副总裁 Peter Eisentraut 随后专门撰文，解释了这一异常现象。其中一个关键变量，正是快速成熟的大模型辅助代码审查与模糊测试。

AI 把以往需要五年才能发现的问题提前暴露了出来

Peter Eisentraut 驳斥了一个容易产生的猜测：这些问题大多并非由“vibe coding”引发。

他解释说，大多数受影响并被最终撤回的功能，早在 LLM 辅助编程和代码审查成熟之前就已完工。换言之，并非开发者让 Claude、Codex 等模型大量生成质量低下的 PostgreSQL 代码，然后在 Beta 阶段集中暴露问题；相反，是日益强大的 AI 审查工具开始重新审视那些按传统流程开发的旧代码。

Peter 将发现的问题大致分为两类。第一类确实较为严重，部分被撤回功能存在架构层面的缺陷，在 Beta 阶段短时间内难以彻底修复。除此之外，还有一系列长尾问题：大量单独看并不严重、仅在特定边缘条件下才会触发的问题。

过去，这类问题通常不会在发布前被察觉。PostgreSQL 会先正常发布，然后在未来几年里，随着真实用户遭遇各种罕见组合，再逐步通过补丁修复。Peter 估算，其中不少问题原本可能要在接下来五年内才会逐渐显现。

LLM 改变了这一流程。借助 AI 辅助代码审查，过去分散在数年间的边缘缺陷，如今可能在几天或几周内被集中扫描出来。

Peter 举例称，开发者可能突然面对大约 40 份缺陷报告。即便每个问题平均只需修改三行代码，但处理每个问题仍需固定成本。代码本身可能只需几分钟改动，但几十个问题累积下来，人类的时间很快就会被耗尽。

这也导致了一个非常反直觉的结果：AI 提升了软件质量，却可能在短期内拖慢了软件发布速度。

Peter 将这种现象概括为“有效质量门槛被抬高”。这些功能当初被开发和提交时，行业尚未具备如今的 LLM 审查能力；等到 PostgreSQL 19 准备发布时，新工具已能发现过去难以察觉的问题。原本可能符合发布标准的代码，在新的审查能力下突然变得“不够好了”。

AI 辅助模糊测试或可直接融入功能开发

数据库尤其容易遭遇这类问题。

PostgreSQL 的一个重要特性是，开发者往往期待不同功能能够自由组合。一个 SQL 功能不仅需要在最普通的情况下运行，还可能被放入 domain、复合类型、分区表、视图、安全定义函数、触发器等各种环境中，且这些能力还能继续相互嵌套。

Peter 举例称，一个 SQL 层面的新功能可能需要应对这样的组合：domain 套在复合类型上，复合类型里的字段本身又是 domain；domain 带有非空约束；列曾被删除又重新添加；表分区被 detach 后又按不同列顺序 attach；最终这一切又出现在一个视图中，而这个视图从触发器中的 security-definer 函数被调用。

理论上，开发者希望所有这些都能正常工作。问题在于，人类甚至很难枚举出所有组合，更不用说逐一手工测试。

LLM 辅助模糊测试恰好擅长此类工作。模型可以不断生成边缘组合、构造测试输入、观察异常，再继续沿异常路径扩展。Peter 因此判断，这类 AI 辅助模糊测试未来很可能需要直接嵌入 PostgreSQL 的功能开发流程，而不能等到 Beta 后期才集中使用。

实际开发过程已出现类似迹象。今年 8 月，PostgreSQL 社区成员 Robert Haas 曾让 Claude 根据 feature freeze 之后修复的 Bug 数量和类型，对 PostgreSQL 19 的补丁进行风险评估。其中，SQL 属性图查询被列为高风险功能之一，当时已历经 17 次修复。

核心开发者 Tom Lane 随后表示，如果 SQL/PGQ 按当时状态进入 PostgreSQL 19，他甚至愿意“赌一顿晚饭”，认为发布后还会发现只能等到 PostgreSQL 20 才能彻底解决的问题。最终，SQL/PGQ 确实被从 PostgreSQL 19 中撤回。

另一名 PostgreSQL 社区成员随后也提到，对该功能启动 AI 审查后，又发现了一些严重问题，并进行了人工确认。这意味着，在这次发布周期中，AI 并不仅仅充当“聊天式代码评论员”，而是已经开始参与真实开源项目的风险筛查。

不过，Peter 也强调，AI 并非这次大规模撤回的唯一原因。部分代码自身质量和架构设计确实存在问题。今年，PostgreSQL 社区还经历了一轮密集的安全问题处理，大量资深开发者从 4 月到 8 月都在忙于修复安全漏洞，导致 Beta 前期本应进行的额外评审和测试受到影响。等这些开发者重新投入 PostgreSQL 19 时，许多问题已经到了发布周期后段才暴露出来。此外，PostgreSQL 自身持续增长的复杂性也是根本问题之一。

大量问题最终迫使 PostgreSQL 社区做出了相当保守的决定。

Peter 称，根据统计方式不同，大约有 8 到 10 项关键功能已从 PostgreSQL 19 分支撤回，其中不少预计将在修正后重新进入 PostgreSQL 20。一个代表性功能是 SQL/PGQ，它用于按 SQL 标准查询由节点和边组成的属性图数据，但由于仍存在未解决的问题，最终未能进入 PostgreSQL 19。

值得注意的是，PostgreSQL 社区此前甚至一度认为 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 的稳定性和可靠性。

AI 无限发现问题，那人类该修到什么程度？

这件事随后在开发者社区迅速发酵。不少开发者认为，软件开发的新瓶颈可能正在从“发现 Bug”转向“给 Bug 分类”。

“这种情况不会很快消失，下一步真正需要解决的是如何对 AI 找出来的问题进行分类，只把最严重的问题优先送到人工审查。”另一些开发者也指出，当找漏洞和构造异常输入的成本突然下降后，“发现问题”和“修复问题”的速度已不再匹配。以前安全研究者找到一个复杂缺陷可能需要几天甚至几周，而 AI 可以同时探索大量路径，人类维护者却仍然只能一个一个确认。

但另一派开发者担心的是，AI 会造成“真假 Bug 泛滥”。

有开发者表示，自己的经验是 AI 会报告大量从局部代码看似合理、放到整个系统语境中却并不成立的问题。如果开发团队机械修复每一个 AI 建议，最终可能得到一个过度设计、效率更差的系统。真正费时间的地方在于，人类必须逐项判断究竟是真 Bug、极端但可以接受的边缘情况，还是纯粹的误报。

一名从事数据工程的开发者称，在其内部 AI 代码审查系统中，即便模型能够访问代码仓库、Confluence 和 JIRA 等上下文，大约也只有八分之一的报告最终被认为有效；对于更通用的审查机器人，这一比例甚至可能进一步下降。另一名熟悉静态分析工具的开发者则表示，大量误报一直都是自动化分析的老问题，一旦积累到十万级缺陷报告，要求人工做到 100% 确认几乎不现实。

不过，有用户也以自身经历证明，即便对误报不满，仍然不愿意放弃 AI 审查，因为它确实能够把隐藏多年的技术债翻出来。他们曾让 AI 对一个已稳定运行约 10 年的客户系统中的脚本、任务和配置进行集中代码审查，最终发现 39 个问题，其中 30 个被确认是真实 Bug，只不过此前从未被触发。

类似事情并不仅仅发生在 PostgreSQL 这样的开源项目中。一些闭源软件里，开发多年的功能同样开始因 LLM 新发现的问题而无法按原计划发布。过去的做法可能是先上线，再在未来版本逐步补丁；但一旦开发团队已经明确知道某个 Bug 或理论漏洞存在，继续把它带进正式版本，在安全和责任层面都会变得越来越难解释。

有开发者指出，数据库这类复杂基础软件中的很多问题，并不是把 Bug 报告重新扔给 LLM，然后点击“自动修复”就能解决。一些缺陷实际上对应的是架构和产品语义上的取舍：某一种行为在使用场景 A 下可能是 Bug，在场景 B 下可能是合理设计，换到场景 C 又可能意味着一年前的基础设计本身需要重做。AI 可以非常便宜地把这种矛盾找出来，但决定“正确行为究竟是什么”依然需要经验丰富的维护者。

甚至已有人担忧出现另一种极端：“发布瘫痪”。如果 AI 可以不断从任何复杂代码库中继续挖出新的边缘问题，那么理论上永远存在下一个 Bug。项目究竟应该修到什么程度才允许发布，未来可能成为比“AI 能找到多少 Bug”更困难的问题。有开发者建议，与其追求在单个版本里消灭所有 AI 找出的缺陷，不如把它们系统化登记、分级，纳入后续开发路线，否则没有任何大型软件能够达到真正意义上的“零缺陷”。

结束语

Claude Code、Codex 等工具的编码能力越来越强后，AI 写代码已不再是问题。而 PostgreSQL 19 事件展现出了，当 AI 同样能够大规模审查、测试和攻击代码之后，“发现问题”也不再是问题。

接下来真正稀缺的，可能变成人类的判断力：哪些问题必须修，哪些问题可以接受；一个三行代码能够修复的边缘缺陷，是否值得为它推迟一个重要功能；AI 给出的几十个问题里，哪几个意味着架构本身需要重新设计；以及当机器可以无休止地寻找异常时，一款软件究竟要达到什么程度，才算“足够好，可以发布”。

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：褚杏娟，36氪经授权发布。