Postgres 19回滚近十项功能，AI代码评审是推手还是背锅？

一次回滚引发的归因之争

PostgreSQL 19 的发布节奏被打乱了。据提交者 Peter Eisentraut 在10月9日的博客中透露，"大约8到10项重要功能，取决于你怎么数"已经从 PostgreSQL 19 中回滚。The Register 在10月16日的报道中确认，原定9月底或10月初的发布时间被推迟，10月15日的 RC1 公告将正式版（GA）定在11月19日，并附带了"除非发现需要延迟或追加候选版本的问题"这一保留条款。

真正让这件事出圈的，是 Eisentraut 给出的原因之一：LLM 辅助代码评审比以往更快地发现问题，"这意味着在功能编写并提交之后，有效的质量门槛被抬高了"。这句话被提炼成标题，随后引来了另一批 Postgres 开发者的反驳。如果你们的团队也在每个 PR 上挂着评审机器人，这场争论的焦点其实同样落在你的评审队列上。

回滚清单：走了什么，留下什么

Snowflake 开发者关系工程师 Elizabeth Garrett Christensen 在9月16日的工程博客中统计，自 beta 阶段开始，PG19 累计出现53次回滚，并列出了其中较大的用户可见功能。

被移除的重量级功能包括：SQL 属性图查询（SQL/PGQ）、ALTER TABLE ... MERGE/SPLIT PARTITION(S)、UPDATE/DELETE ... FOR PORTION OF、GROUP BY ALL，以及在线数据校验和（online data checksums）。The Register 指出，SQL/PGQ 是因未解决的问题被撤下的——该特性自2023年起就是 SQL 标准的一部分。Tom Lane 在9月曾表示，他"愿意用一顿晚饭打赌"，如果 v19 强行发布它，产生的线上 bug 要到 v20 才能修复。

留下来的功能同样值得关注。Eisentraut 点名了 REPACK CONCURRENTLY、序列的逻辑复制和 pg_plan_advice。RC1 的发布说明还列出了 Beta 4 以来对 REPACK (CONCURRENTLY) 和 pg_plan_advice 的修复，以及并行 autovacuum 和 COPY (query) TO ... (FORMAT json)。Eisentraut 预计许多被回滚的功能会回归，但最快也要等到 PostgreSQL 20。

SQL/PGQ（SQL Property Graph Queries）是 SQL:2023 标准引入的属性图查询扩展，允许在关系表上以顶点和边的图模型直接书写 MATCH 模式查询，而无需额外图数据库。对 PostgreSQL 而言，这意味着要新增一套图模式解析、路径匹配执行器和目录元数据，牵涉面远超普通语法糖。它自 2023 年成为标准后备受期待，但实现复杂度高、边角语义多，正是 Tom Lane 担心“强行发布后 bug 要拖到 v20 才修”的典型对象。

REPACK CONCURRENTLY 则是 PostgreSQL 长期缺失的运维能力：传统 VACUUM FULL 或 CLUSTER 会持有排他锁、阻塞读写，而 REPACK 旨在以在线方式重写表并回收空间。它能留在 19 中，对需要控制表膨胀的生产环境是实质性利好。

AI 抬高了门槛：一种解释

Eisentraut 的博客没有点名任何工具或模型，谈的是 LLM 辅助代码评审这一整体现象，他的论点落在时机上。评审现在能抓到那些在 beta 阶段难以修复的架构级缺陷，外加一长串边角案例问题，而"处理每一个都有固定开销"。他明确否认这是"vibe coding"造成的，因为受影响的代码早于这种实践出现。

他在同一篇文章里给出了第二个原因。由于他所说的"漏洞末日"（Vulnpocalypse），许多资深开发者在4月到8月期间忙于安全修复，而不是 beta 测试和评审。

Snowflake 的9月文章把 AI 放得更靠中心："AI 必须是解释当前局面的故事的一部分。"该文还提到，"PostgreSQL 目前没有官方的 AI 贡献政策，但预计很快会有"。

“Vulnpocalypse”（漏洞末日）是 PostgreSQL 社区对 2025 年安全漏洞集中爆发期的戏称。文章提到去年约 5 个 CVE、今年已达 44 个，量级跃升意味着提交者需要投入大量时间做安全评估、打补丁和协调披露，而这些人同时正是 beta 测试与代码评审的主力。安全修复具有硬性时间压力，beta 评审则相对弹性，于是评审被系统性推迟。这一背景很重要：它说明回滚潮未必源于“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 自己的设计判断。Pettus 对此的总结是："过滤本身就是评审。"

两派的机制描述其实一致：评审来得晚，而当它到来时，发现的问题超出了项目在发布前能修复的量。分歧只在于其中有多少是模型找到的。

“过滤本身就是评审”指向 AI 辅助评审的真实工作流：模型产出的发现往往夹杂误报和过度推断，资深提交者必须逐条判断哪些成立、哪些是设计取舍、哪些是模型误解了上下文。Noah Misch 驳回四个发现中的三个，说明模型的价值不在于结论正确率，而在于把候选问题摆到人面前，由人完成筛选与定性。因此归因之争容易失真：若以“回滚是否由 AI 触发”计数，会低估 AI 的作用；若以“评审中是否用过模型”计数，又会高估。更合理的口径是看模型发现经过滤后真正改变了设计决策的比例。

对普通团队的三个迁移结论

你可能不维护数据库，但你的 PR 上可能已经挂着评审机器人。有三点可以直接搬过来。

把昂贵的评审放到合并之前。 Eisentraut 的核心观察是质量门槛在功能提交之后才移动。在开放的 PR 上，一个发现只是一条评论；同样的发现如果发生在代码合并之后，代价可能是一次回滚。

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

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

如果你的升级计划排在10月

计划需要改。PostgreSQL 官方的 beta 测试页面写明，beta 和候选版本"不适用于生产系统"，Snowflake 的9月文章建议现阶段以 PostgreSQL 18 作为安全的升级目标。

RC1 是测试的好时机。用 19 版本 $NEW_BIN 中的 pg_upgrade 二进制，对数据副本和全新初始化的 19 集群执行 --check，它只做兼容性检查、不改动任何数据：

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 测试指南说明了如何报告发现的问题，开放事项列表则展示了仍在修复中的内容。

这场关于归因的争论最终指向一个更朴素的事实：发现问题的成本已经降到接近零，但阅读、判断并为结论负责的成本没有。评审机器人不解决后者，它只是把后者暴露得更明显。

pg_upgrade --check 只验证新旧集群的兼容性——包括目录结构、数据类型、排序规则和扩展版本——不会迁移数据，也不修改原集群，因此可以安全地在数据副本上反复运行。它不能替代真实升级演练：实际执行 pg_upgrade 时还需考虑链接模式与拷贝模式的取舍、大对象和 pg_statistic 的迁移、以及升级后 ANALYZE 的耗时。对计划迁移到 19 的团队，建议先用 --check 排除硬性不兼容，再在非生产副本上完整跑一遍升级并验证关键查询，最后才安排生产窗口。