PostgreSQL 19 大量功能回滚，一位维护者复盘成因

许多读者可能已经注意到，beta 测试期开始后，从 PostgreSQL 19 分支回退（revert）的特性数量异常地多。出现一些回退并不罕见，可能每个版本周期都会有一两个。但这一次，根据不同的统计方式，大约有 8 到 10 个重要特性被回退，而且其中一些发生在 beta 期的较晚阶段。我本人也亲身经历了其中一些——作为其中部分特性的开发人员或提交者——也因此收到了一些相关提问，所以我想花一点时间来谈谈这个问题。我会尝试对其余一些我并未直接参与的、同样受到影响的工作做一些推断，但这些目前都只是我个人的看法。

那么到底发生了什么？

我认为我们——也就是所有受影响的开发人员——还没有足够的时间来充分反思这一切。不过这里有一些初步的想法。情况很可能是多种因素共同作用的结果，而对于每个被回退的特性，这些因素的组合也各不相同。

• 也许我们只是没有把工作做到足够好。也许代码本身的质量确实不够。我们会从中学习并改进。这其中应该有一部分原因，我在这里提到它，是不想让大家误以为原因仅在于接下来我要谈到的其他因素。

• 这也可能只是巧合。或许我们之前一直顺风顺水，以至于同时尝试攻克了若干特性，结果却发现这些特性过于困难，或者说至少难以在规定时间内完成。

• 一些被回退的特性存在相当严重的架构性缺陷，要在 beta 期间快速修复是很困难的。但同时还存在一系列相对不那么严重的问题，涉及各种各样的边界情况。在过去，这些问题中的许多可能要等到发布很久以后才会浮出水面，而我们会随后续的五年时间一点一点地修补它们。但借助 LLM 辅助的代码审查，这类问题能够被更快地发掘出来，于是你就会面对一份长达约四十条的缺陷报告。即便平均每个缺陷只需要三行代码的修改，处理每一条仍然存在一个固定的额外开销，加起来时间就不够用了。大多数（如果不是全部）受影响并被回退的特性都是在很久以前写就的，那时 LLM 辅助代码审查还没有如今这么有用，也就是说，在这些特性被编写和提交之后，事实上有效的质量标准被抬高了。除非 LLM 辅助代码审查的能力继续以目前的速度提升，否则这种情况在未来的开发周期中应当会自行得到缓解。

• 由此可以推出一个推论：至少就我所观察到的绝大部分情况而言，这种状况并非由“氛围编程”（vibe coding）造成。这些代码的编写时间远远早于那种做法成为可能的时代。

• 由于 Vulnpocalypse 事件，许多资深开发者在四月（PostgreSQL 19 功能冻结的开始，同时也是 Vulnpocalypse 的开端）到八月（最近一次 PostgreSQL 安全发布）之间一直忙于修复安全问题。正因如此，测试版期间原本应有的额外审查与测试有所减少，直到八月才重新恢复。这很可能就是为何大量新问题在测试版后期才被发现、为何如此多的回退操作发生得那么晚——也让这一切显得格外引人注目。同样地，有些问题更为根本，但同时也存在大量小问题的长尾，我个人觉得如果有更多时间——比如说两个月——这些问题本来是可以被解决的（前提是有足够的专注，但请注意 Vulnpocalypse 仍在持续）。然而社区更倾向于坚持按既定的发布计划推进，而不是为了纳入更多修复而延期。（而且长尾究竟有多长，谁也无法预知。）

• 系统的复杂性使得某些类型的功能要做对极其困难，代码中也没有足够的支撑框架来应对。以某个 SQL 层级的查询语言特性作为抽象示例来说明：它能配合域（domain）工作吗？那么基于复合类型的域呢？其中一个字段本身也是一个域呢？这个域还带有非空约束呢？其中某一列被删除之后又重新添加了呢？这是某个表分区的一部分，而该分区已经被分离并以不同的列顺序重新附加了呢？这是某个视图的一部分，而该视图是从一个触发器中的安全定义者函数调用的呢？类似的情况不胜枚举。没有人能够手工测试这些场景，甚至无法一一枚举这些测试用例。但借助 LLM 辅助的模糊测试可以非常迅速地发现其中的问题。因此，这很可能需要在未来的功能开发中纳入考量。但我们也应当考虑让内部接口更加健壮，使得每一种不同的上下文组合不会引发出如此众多的新交互可能。

  我喜欢说，在 PostgreSQL 中，“一切都能与一切协同工作”。这是其魅力的一部分——你能够构建这样的用例并期望它们能够正常工作。我一点也不希望放弃这一点。但它确实给功能开发带来了一项显著的成本，这是所有人都需要意识到的。

• 最后，PostgreSQL 开发社区一段时间以来一直在思考这样一种可能性：即以某种“实验性”状态提交功能，然后在主干代码中逐步使其走向成熟。这也是应对前述问题的一种可行方案。对于至少一部分被回退的功能来说，这将是一个很有用的工具，但我们至今还没有想出具体可行的实施方式，而且相关工作中有一部分还因围绕该议题的误解而受到了影响。这是一个切实有待推进的要点。

那么接下来呢？

首先，从我个人的角度出发，感谢所有亲自或在线上表达过支持与鼓励的朋友们。这是最重要的事情。我相信许多被回退的功能在不久的将来都会重新回归。

PostgreSQL 19 依然会是一个出色的版本。REPACK CONCURRENTLY、序列的逻辑复制（其本身也是一项此前被回退过的功能）、以及通过 pg_plan_advice 实现的规划器提示——仅举几项亮点——就会让这个版本极具吸引力。而经过如此多额外的严格审视之后，它也将会非常稳健。

现在很难预测事情。几个月前我说，PostgreSQL 20 可能没有新特性，只有 bug 修复。结果事情发展得更快，PostgreSQL 19 现在，可以说，只有当时预期的一半主要特性，但现在我们也已经有一些不错的完成了 80% 的特性在排队等着进 PostgreSQL 20，只差剩下的 80% 就能搞定！