PostgreSQL 19 推迟三周：AI 审查太狠，人类修 Bug 的速度跟不上了

一个数据库大版本的发布延期，通常不会成为新闻。但 PostgreSQL 19 这次不一样：原定 10 月 29 日发布，被推迟到 11 月 19 日，中间还额外加了一个 11 月 12 日的 RC2。官方给出的理由很朴素——近期进入各维护分支的修复太多，希望先让社区验证一轮。

真正让开发者社区炸开锅的，是延期背后那个反直觉的原因：AI 辅助代码审查和模糊测试，把过去要五年才会逐渐暴露的边缘缺陷，在几周内集中翻了出来。

一分钟速览

• 时间表：正式版从 10 月 29 日推迟到 11 月 19 日；10 月 15 日已推进 RC1，11 月 12 日新增 RC2。
• 撤回了多少：Beta 阶段开始后，约 8 到 10 项重要功能被从 PostgreSQL 19 撤回，部分是在相当靠后的阶段才移除。
• 不是 vibe coding 的锅：核心提交者 Peter Eisentraut 明确表示，多数被撤回的功能在 LLM 辅助编程成熟之前就已完成；是后来更强的 AI 审查工具重新检查了旧代码。
• 问题类型：一类是架构层面的缺陷，Beta 阶段难以彻底修正；更多是只在特定边缘条件下触发的长尾问题。
• 代表性案例：SQL 属性图查询 SQL/PGQ 被撤回，核心开发者 Tom Lane 曾表示若按当时状态发布，他愿意“赌一顿晚饭”认为会留下只能等 PostgreSQL 20 解决的问题。
• 仍然保留的能力：REPACK CONCURRENTLY、序列的逻辑复制、通过 pg_plan_advice 实现的查询规划器提示等。

AI 把“未来的补丁”提前变成了“今天的阻塞”

Eisentraut 的解释里有一个关键判断：这些缺陷并不是新产生的，它们一直存在。按过去的节奏，PostgreSQL 会正常发布，然后在未来几年里，等真实用户撞上各种罕见组合，再一点点打补丁。他估计，不少问题原本可能要在接下来五年内才逐步浮现。

LLM 改变了这个时间分布。借助 AI 辅助审查，分散在数年里的边缘缺陷，可能在几天或几周内被集中扫出来。于是出现了一个很少被讨论的副作用：AI 提高了软件质量，却可能在短期内降低发布速度。

他把这种现象概括为“有效质量门槛被抬高了”。这些功能开发和提交时，行业还没有今天这样的审查能力；等到准备发布时，新工具已经能发现过去难以发现的问题。原本符合发布标准的代码，在新标准下突然“不够好了”。

为什么数据库特别容易中招

PostgreSQL 的一个特点是鼓励功能自由组合。一个新 SQL 功能不只要在普通场景下工作，还可能被放进 domain、复合类型、分区表、视图、安全定义函数、触发器里，而且这些能力还能继续互相嵌套。

Eisentraut 举了一个极端例子：domain 套在复合类型上，复合类型里的字段本身又是 domain；domain 带非空约束；列曾被删除又重新添加；表分区被 detach 后按不同列顺序重新 attach；最后这一切出现在一个视图里，而这个视图从触发器中的 security-definer 函数被调用。

人类很难枚举出所有组合，更不用说逐个手工测试。而这正是 LLM 辅助模糊测试擅长的部分：不断生成边缘组合、构造输入、观察异常，再沿着异常路径继续扩展。他因此判断，这类测试未来需要直接进入功能开发流程，而不是等到 Beta 后期才集中使用。

修复成本不在代码行数，而在判断

一个容易被忽略的细节是：开发者可能突然面对约 40 份缺陷报告。即便每个问题平均只需要改 3 行代码，处理每一个问题仍有固定成本——复现、确认、评估影响、写测试、回滚风险。代码只改几分钟，几十个问题叠加起来，人的时间很快就被耗尽。

社区里的分歧也在这里。一派认为瓶颈已经从“发现 Bug”转移到“给 Bug 分类”，下一步要解决的是如何把最严重的问题优先送到人工审查；另一派担心 AI 制造“真假 Bug 泛滥”。有开发者说，在其内部 AI 审查系统中，即便模型能访问代码仓库、Confluence 和 JIRA，大约也只有八分之一的报告最终被认定有效。

但同一批开发者里，也有人不愿意放弃 AI 审查。有人让 AI 集中检查一个稳定运行约十年的客户系统中的脚本、任务和配置，最终报出 39 个问题，其中 30 个被确认为真实 Bug，只是此前从未被触发。

“发布瘫痪”是更远的风险

如果 AI 可以不断从任何复杂代码库里挖出新的边缘问题，那么理论上永远存在下一个 Bug。项目究竟要修到什么程度才允许发布，可能会成为比“AI 能找到多少 Bug”更难回答的问题。

这也是 PostgreSQL 19 留下的真正问题。它没有证明 AI 审查不可靠，反而证明了它有效；它暴露的是配套机制的缺失——当发现问题的成本趋近于零，分类、定级、取舍的能力就成了稀缺资源。把这些报告系统化登记、分级，纳入后续路线，可能比在一个版本里追求“零缺陷”更现实。

对使用 PostgreSQL 的团队来说，这次延期不是坏消息。一个被多审查了一轮的版本，通常更稳。但它提醒所有人：AI 把软件工程的瓶颈从“写”和“找”，推到了“决定什么值得修”。这项工作要求经验，也要求有人愿意为取舍负责。