Postgres 19延期：AI评审惹的祸？

大约8到10个重要功能，具体数字取决于你怎么数，已经从 PostgreSQL 19 里被撤掉了。提交者 Peter Eisentraut 在 10 月 9 日写下这句话时，给出的原因之一是 LLM 辅助的代码评审——它找缺陷的速度比过去快得多，"这意味着在功能写完并提交之后，有效的质量门槛被抬高了"。

时间表也跟着动了。PostgreSQL 19 原本安排在 9 月底或 10 月初发布。10 月 15 日的 RC1 公告把正式可用日期定在 2026 年 11 月 19 日，"除非发现需要延期或追加候选版本的问题"。

那句关于评审的话成了标题。同样翻看撤稿记录的 Postgres 开发者们，得出了不一样的答案。如果你的 PR 上挂着评审机器人，这场分歧也关乎你的队列。

走了什么，留下什么

9 月 16 日，Snowflake 开发者倡导者 Elizabeth Garrett Christensen 的一篇文章统计，自 beta 启动以来 PG19 共有 53 次撤稿，并列出了其中较大的用户可见功能：

• SQL 属性图查询（SQL/PGQ）
• ALTER TABLE ... MERGE/SPLIT PARTITION(S)
• UPDATE/DELETE ... FOR PORTION OF
• GROUP BY ALL
• 在线数据校验和

SQL/PGQ 自 2023 年起就是 SQL 标准的一部分，因未解决的问题被撤。Tom Lane 在 9 月说过，他"愿意赌一顿晚饭"：把它放进 v19 会产生发布后才暴露、要到 v20 才能修的 bug。

留下的功能里，Eisentraut 点名了 REPACK CONCURRENTLY、序列的逻辑复制和 pg_plan_advice。RC1 说明还列出了 Beta 4 以来针对 REPACK (CONCURRENTLY) 和 pg_plan_advice 的修复，以及并行 autovacuum 和 COPY (query) TO ... (FORMAT json)。他预计不少被撤功能会回归，那最早也是 PostgreSQL 20 的事。

AI 评审抬高门槛的说法

Eisentraut 的帖子没有点名任何工具或模型，谈的是一般意义上的 LLM 辅助代码评审，论点落在时机上。评审现在能抓出 beta 期间难以修复的架构缺陷，还有一长串较小的边缘问题，"而处理每一个都有固定开销"。他明确表示，情况"不是因为'氛围编程'"，受影响的代码早于这种做法出现。

他在同一篇帖子里给了第二个原因：因为所谓的"漏洞末日（Vulnpocalypse）"，许多资深开发者大约从 4 月到 8 月都在忙安全修复，而不是做 beta 测试和评审。

Snowflake 9 月的文章把 AI 放得更靠中心："AI 必须是解释我们为何陷入这种处境的一部分。"文章还提到，"PostgreSQL 目前没有官方的 AI 贡献政策，不过预计很快会有"。

人类评审来得太晚的说法

另一位提交者 Tomas Vondra 翻查了 5 月 20 日到 9 月 16 日之间 12 次撤稿背后的邮件列表讨论，逐一核对问题是否由 AI 发现。他的结论是："只有 4 个属于'可能是 AI'或'AI'。"PostgreSQL 顾问 Christophe Pettus 指出，Vondra 对单次撤稿的判定比这个标题更吝啬：一个判为 AI，一个可能是 AI，两个大概不是。

Vondra 的解释是评审积压。他按开发周期天数统计以"Revert"开头的提交：功能冻结大约在第 275 天，发布通常在第 480 天左右，而 PG19 的撤稿在第 430 天附近出现尖峰。至于评审为何来得这么晚，他指向安全工作："去年我们大概有 5 个 CVE，今年已经到了 44 个。"他称这是"稳定期评审活动下降的主要原因之一"。

Pettus 的判断是："这些撤稿不是 AI 发现了无法修复的 bug。"AI 确实出现过，通过资深贡献者和公开讨论串。Vondra 的帖子提到用 Opus 4.8 和 Opus 5 做过的评审，以及几个讨论串里对 Claude 的使用。Pettus 写道，Noah Misch 用模型评审的那次提交里，驳回了四个发现中的三个，撤稿来自 Misch 自己的设计判断。他的说法是："过滤就是评审。"

两边描述的是同一个机制：评审来得晚，来的时候发现的问题超出了发布前能修完的量。分歧只在于其中多少是模型找出来的。

产出一个发现很便宜。总得有人去读、去判断、去为答案负责。

你的团队跑 AI 评审，能带走什么

你多半不维护数据库，但你的每个 PR 上可能都挂着评审机器人。三件事可以照搬。

把昂贵的评审放在合并之前。Eisentraut 的要点是质量门槛在功能提交之后移动了。开着的 PR 上一条发现，成本是一个评论；代码合并后同一条发现，成本可能是一次撤稿。

为分诊留预算。"处理每一个都有固定开销"同样适用于你的团队。一个产出的发现多到没人读得完的评审者，只会把队列拉长。

每个判定都保留人类作为责任人。Pettus 希望 PostgreSQL 写下其他项目 AI 政策已有的形状："辅助使用没问题。AI 作为贡献者不行。人类评审并拥有结果。"他提议的规则里有一条更短："为你发的每一点负责。"Misch 扔掉四个模型发现中的三个，就是这条规则在起作用。

你的 Postgres 升级怎么办

如果你原计划 10 月升级到 PostgreSQL 19，往后挪。项目的 beta 测试页面写明，beta 和候选版本"不适用于生产系统"，Snowflake 9 月的文章建议目前把 PostgreSQL 18 作为安全的升级目标。

RC1 倒是测试的好时机。用 19 的 pg_upgrade 二进制，把 pg_upgrade --check 指向一份数据副本和一个全新初始化的 19 集群，它只检查兼容性，不改动任何数据：

pg_upgrade --check \
--old-bindir "$OLD_BIN" \
--new-bindir "$NEW_BIN" \
--old-datadir "$OLD_DATA" \
--new-datadir "$NEW_DATA"

然后对照上面的清单读 PostgreSQL 19 的发布说明。如果你的计划依赖 GROUP BY ALL、SQL/PGQ 或分区合并与拆分命令，把它们从 19 的计划里拿掉。wiki 的 beta 测试指南说明了如何报告发现的问题，未决事项列表则显示还有哪些在被修复。