PostgreSQL 社区是时候延长版本开发周期了！

一次回退三大主力特性的背后，是多家厂商、多位贡献者的辛勤研发工作成果。

目录

一场 “史无前例” 的回退风暴

2026 年 9 月，PostgreSQL 社区发生了一件让所有人都始料未及的事：PostgreSQL 19 还没正式发布，三个最受期待的核心特性就被接连回退，直接从代码库中连根移除。

• SQL/PGQ 属性图查询：9 月 7 日回退，一次性删掉 47 个 commit，上百个文件、上万行代码。回退理由是 “设计层面存在大量深层问题，当前发布周期内根本解决不了”。
• MERGE/SPLIT PARTITION 分区在线拆分合并：8 月 27 日回退，移除 14 个 commit。提交描述写得很直白：“多处设计问题，在当前发布周期内已经来不及解决了”。
• GROUP BY ALL 语法：因搭配 ORDER BY 时会返回错误的查询结果，需要重构优化器逻辑，Beta 后期风险不可控，同样被回退。

连 PostgreSQL 核心团队的 Bruce Momjian 都在邮件列表里感叹：“我们正处在一个史无前例的境地”。

而另一位社区资深人士 Joshua Drake 更是直接提出了一个大胆的建议：把 PostgreSQL 19 的发布时间推迟到 2027 年春天。他的理由很简单：

确实如此，更关键的是，这关乎整个社区对这个版本的信心。

眼下讨论要回退的特性数量不在少数，无论我们最终是否回退这些功能，大家对这一版的信心都已经下降了。

对此我提议，将版本发布时间推迟到 2027 年春季。这样做有多方面的意义：

1. 给这些特性留出充分的成熟时间，随着时间推移，我们可以对其质量做出更明确、更笃定的判断。

2. 如果将它定为新的时间线，还能解决开发周期里一个长期存在的问题：我们的测试窗口刚好落在夏季。

我还没有遇到任何客户跟我说业务受阻，或者 “必须要用” 19 版本。 说实话，大部分人甚至还没跑上 18 版本，我们这么急着赶进度到底是为什么？

我宁可要一个晚到但完整的 19 版本，也不愿看到这些出色的特性、大家投入的心血都被腰斩。

这场风暴暴露的，不仅仅是 PostgreSQL 19 这一个版本的问题，而是整个社区一年一个大版本的开发周期，可能真的该改一改了。

一年一个大版本，对 PostgreSQL 来说太短了

PostgreSQL 长期保持着每年 9 月发布一个大版本的节奏。这个节奏在过去很多年里运行良好，但随着数据库内核复杂度的不断攀升，一年的时间正在变得越来越不够用。

我们不妨对比一下同类开源数据库 MySQL 的发布节奏：

MySQL 从 8.0 到 8.4 LTS 之间隔了整整 6 年，即使算上创新版本，大版本的迭代节奏也远比 PostgreSQL 宽松。这意味着 MySQL 的开发者有更充裕的时间去打磨一个大特性，去做充分的测试和验证。

而 PostgreSQL 呢？一个大特性从设计、实现、评审、合入到 Beta 测试，全部要压缩在一年的时间窗口里。Feature Freeze 通常在 4 月，之后就只能修 bug 不能加新功能。这意味着一个复杂特性如果在 3 月才合入主干，留给它在真实场景下暴露问题、修复问题的时间，可能只有短短几个月。

PostgreSQL 19 的 SQL/PGQ 特性就是典型的例子。作为 SQL 标准定义的原生图查询能力，它涉及查询解析、优化器、执行器、权限体系、pg_dump 兼容性等方方面面。这么庞大的一个特性，要在一年的周期里从设计到稳定，几乎是不可能完成的任务。最终的结果就是，设计层面的深层问题在 Beta 阶段集中爆发，只能整体回退。

更值得注意的是，Joshua Drake 在邮件中提到了一个长期存在的问题：PostgreSQL 的测试窗口正好在夏天。 夏天是很多开发者休假的季节，测试人力本身就不足。如果开发周期能延长，测试窗口也可以调整到更合适的时间。

延长周期，让大特性有时间 “长熟”

延长版本开发周期最直接的好处，就是让大特性的问题修复时间更加宽裕。

一个数据库内核的大特性，从合入到真正稳定，往往需要经历多个阶段：

1. 基础框架合入：核心数据结构和基础设施进入主干
2. 功能逐步补齐：在基础框架之上逐步添加上层功能
3. 边界场景打磨：处理各种异常情况、并发冲突、兼容性问题
4. 性能调优：在真实负载下验证性能表现
5. 长期稳定性验证：在 Beta 阶段经过大量用户测试

这五个阶段，每一个都需要时间。一年的周期里，前两个阶段可能就占去了大半年，留给后面三个阶段的时间被严重压缩。结果就是，特性看起来 “做完了”，但实际上远没有 “做熟”。

PostgreSQL 19 的回退事件就是最好的教训。如果开发周期是两年，SQL/PGQ 完全可以在第一年合入基础框架，第二年逐步补齐功能、修复设计问题，最终以一个成熟的状态出现在正式版本中。而不是像现在这样，在 Beta 阶段发现根本修不完，只能一刀切掉。

延长周期还能带来一个隐性收益：降低版本升级的频率和成本。 对于企业用户来说，每一次大版本升级都是一次有风险的操作。版本发布得越频繁，升级的压力就越大。Joshua Drake 在邮件中说得很实在：“大多数人甚至还没跑上 18，我们急什么？”

但光延长周期还不够，大特性要学会 “分步走”

延长开发周期是给大特性更多时间，但这并不意味着开发者可以把一个庞大的特性憋到最后一刻才一次性合入。恰恰相反，对于大特性的合入，开发者应该尽可能拆分成多个阶段，逐步合入。

这方面，PostgreSQL 的**异步 I/O（AIO）**特性就是一个非常好的正面案例。

AIO 的开发跨越了多个版本，采用了典型的 “分步走” 策略：

• 第一步（PG17 前后）：合入 AIO 核心基础设施，包括 PgAioHandle 句柄管理、worker 模式和 io_uring 模式的底层支持。这一步只做基础组件，不涉及上层业务逻辑。
• 第二步（PG18）：在核心基础设施之上，合入缓冲区管理器（Buffer Manager）的异步读支持，让顺序扫描的预读（readahead）可以使用 AIO。同时引入 io_method GUC 参数，用户可以选择 worker 或 io_uring 模式。
• 第三步（PG19 及以后）：逐步将更多读取路径转换为使用 AIO，探索 Direct I/O（debug_io_direct）支持，优化脏页写出等场景。

这种分步合入的策略有几个明显的优势：

第一，每一步的改动范围可控，评审难度低。 一次性提交上万行代码的大 patch，评审者很难发现深层问题。而拆分成多个小阶段，每个阶段的改动聚焦在一个明确的范围内，评审质量自然更高。

第二，问题可以更早暴露。 基础框架合入后，在后续版本的日常使用中就会持续接受测试。等到上层功能开始构建时，底层的问题大概率已经被发现和修复了。而不是像 SQL/PGQ 那样，整个特性一起合入，问题在 Beta 阶段才集中爆发。

第三，即使某一步出了问题，回退成本也低。 如果 AIO 的上层功能在某个版本发现问题，只需要回退上层的改动，核心基础设施不受影响。而 SQL/PGQ 是整体设计、整体合入，出了问题只能整体回退，47 个 commit 一起删，之前所有的修复工作全部白费。

第四，用户可以逐步体验和反馈。 PG18 用户已经可以在顺序扫描场景下使用 AIO 并提供反馈，这些反馈会直接指导 PG19 的后续优化。这比憋到最后一次性发布，然后在正式版本里才发现问题，要好得多。

PostgreSQL 社区其实已经有这样的智慧，AIO 的分步合入就是证明。问题在于，不是所有大特性都遵循了这个模式。SQL/PGQ、分区拆分合并这些特性，更倾向于 “整体设计、整体合入”，最终在一年的紧周期里翻车。

写在最后

PostgreSQL 19 的这场回退风暴，是一个信号。它告诉我们：一年一个大版本的节奏，在数据库内核复杂度日益增长的今天，已经开始显得力不从心了。

延长版本开发周期，可以让大特性有更充裕的时间去修复问题、打磨细节；而大特性本身采用分步合入的策略，则可以让每一步都走得更稳、更扎实。两者结合，才能让 PostgreSQL 的每一个大版本都真正 “值得等待”。

正如 Joshua Drake 所说：宁可要一个迟到但成熟的版本，也不要一个匆忙但被掏空的版本。

参考

PostgreSQL 邮件列表：scary patch contest