Postgres 19 延期：AI 审查的 bug 修不完

一个以"慢"出名的数据库，这次延期的理由很反常：不是没人写代码，是没人修得完。

一、发生了什么

据 The Register 10 月 16 日报道，PostgreSQL 全球开发组把 19 版的正式发布从原定的九月底、十月初，推到了 11 月 19 日前后。同时撤回了 8 到 10 个重要特性，这些特性顺延到明年的 20 版。

核心提交者、EDB 副总裁 Peter Eisentraut 在 10 月 9 日的博客里解释了原因，其中一部分要算在 LLM 辅助代码审查头上。他说，被撤的特性里，有些存在架构层面的缺陷，在 beta 阶段没法"快速"修掉；另一部分问题则是长尾的边缘情况，放在过去，多半会在上线后五年里被零零散散地发现，然后打补丁。

他给了一笔很具体的账：LLM 审查把这些小问题提前挖了出来，于是你面前摆着四十份缺陷报告。每份平均可能只要改三行，但每一份都要复现、写测试、评审、讨论，这些固定开销省不掉，时间就这么用完了。

被撤掉的最显眼特性是 SQL/PGQ，也就是 SQL 标准 2023 版里的属性图查询语法。提交者 Tom Lane 在撤回前就警告过，如果硬塞进 19 版发布，会出现直到 20 版才修得了的线上缺陷。保留下来的包括 REPACK CONCURRENTLY，它能在不锁表的情况下回收磁盘空间，不像 VACUUM FULL 那样把表锁住。

Eisentraut 特意强调，这不是"氛围编程"造成的——大部分特性写的时候，AI 编程工具还没现在这么普及。变的是审查：代码写完之后，合格线被抬高了。

二、跟你有什么关系

用 Postgres 的人：短期少了一批新特性，但换来的是一版被反复挑过刺的代码。如果你本来就要在四季度做升级评估，时间窗口已经挪到 11 月中下旬，计划得跟着动。

在团队里推行 AI 代码审查的人：这是一个提前上演的剧本。审查能力提升的速度，可能远快于你处理审查结果的能力，中间那段落差会直接变成排期风险。

做开源维护的人：以前"发现问题"贵，"修问题"便宜；现在反过来了。一个项目能承受多少缺陷报告，取决于有几个能拍板的人，而不是有几个能扫代码的模型。

顺带一个细节：这次延期并没有伴随"质量事故"。按 Eisentraut 的说法，撤回是为了不在正式版里留下 beta 期间修不掉的坑。对使用者来说，坏消息是晚了一个多月，好消息是少了一批上线后才知道的坑。

三、怎么用：把 AI 审查接进流程的三条

1. 先算修复产能，再开审查强度。统计一下团队一周能真正关闭多少条 review 意见，这就是上限。超过这个量的报告不会消失，只会积压成一张没人看的清单。

1. 按"能不能在发布前修完"分流，而不是按严重度排。Eisentraut 那四十份报告，单看都不严重，合起来才压垮排期。给"边缘情况"设一个时间盒，到点没修完就明确推到下个版本，比含糊地挂着强。

1. 把审查结论写进发布说明。哪个特性因为什么被撤、什么问题留到下一版，写清楚。Postgres 这次做得好的一点，是让人知道延期不是因为乱，而是因为有账可算。

四、三个别信的说法

"AI 审查能让发布更快。" 它让"发现"更快，但不让"修完"更快。发现和修复是两条流水线，只有前一条提速，结果是中间堆货。

"延期说明 AI 生成的代码质量差。" 这次恰恰不是。被撤的特性大多写在 AI 编程普及之前，问题是审查标准在代码冻结之后才提高。用这件事证明"AI 写代码不行"，是读错了因果。

"一次撤十个特性，说明项目管理失控。" 报道里的解释更朴素：有些特性本身太难，有些在 beta 期间赶上安全修复潮、资深评审被抽走，再加上审查变严。三个因素叠在一起，才走到撤回这一步。

五、一句话结论

AI 把"找 bug"变成了廉价动作，但修 bug 的还是那几个人；当两者速度不匹配，延期就是必然结果。

信息来源

• The Register，Postgres 19 delayed after AI reviewers find more bugs than humans can fix，2026 年 10 月 16 日：https://www.theregister.com/databases/2026/10/16/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix/5303471
• Peter Eisentraut 博客《The reverts will continue until morale improves》，2026 年 10 月 9 日（经上述报道引用）

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。