由 John Doe 九月 9, 2026
三大主力特性，全部被正式回退，直接从代码库中移除。还有一个REPACK CONCURRENTLY也可能会保不住。
目录
8 月 13 日，PostgreSQL 全球开发组发布了全系列维护版本更新与 PostgreSQL 19 Beta 3。本该是新特性集中亮相的节点，社区却迎来了意外的 “反向更新”：三个最受期待的核心主力特性，全部被正式回退，直接从代码库中移除。
一边是单批次修复 28 个 CVE、上百个 Bug 的高效安全治理，一边是重量级新特性的集体回撤。这一进一退之间，藏着数据库内核开发最朴素的真相：AI 或许能加速漏洞发现，但永远加速不了内核的成熟周期。
Beta 3 最大意外：三大重磅特性全部回退
在 PostgreSQL 19 特性冻结之初，属性图查询、分区在线拆分合并、GROUP BY ALL 语法被视作最值得期待的三大功能。谁也没想到，到了第三个 Beta 版本，它们迎来的不是打磨完善，而是整体回退。
1. SQL/PGQ 属性图查询：整个特性被连根移除
这是本次回撤中分量最重的一项。SQL 属性图查询（SQL/PGQ）是 SQL 标准定义的原生图查询能力，被很多人视作 PostgreSQL 对标图数据库的标志性功能。
根据社区提交记录，整个 SQL/PGQ 特性被完整回退，涉及上百个文件、上万行代码的删减。回退原因很直接：设计层面存在大量深层问题，当前发布周期内根本解决不了。从聚合子查询支持、内存溢出风险，到 pg_dump 兼容、权限体系，方方面面都存在未收敛的设计缺陷，最终只能整体移除，留待未来版本重新设计。
2. MERGE/SPLIT PARTITION：分区运维语法彻底撤销
第二项被砍的是 DBA 期盼已久的分区运维语法：ALTER TABLE ... MERGE/SPLIT PARTITION(S)。
在此之前，拆分或合并分区需要手动建表、迁移数据、替换约束，流程繁琐且风险高。该特性原本可以用一条 SQL 完成全部操作，大幅降低分区运维门槛。但社区在测试中发现其存在多处架构级设计缺陷，修复链路长、影响范围大，无法在 19 周期内达到稳定标准，最终决定全部回退。
3. GROUP BY ALL：热门语法糖因正确性问题推迟
第三项回退的是开发者呼声很高的易用性特性GROUP BY ALL。它可以自动将 SELECT 中的非聚合列纳入分组，不用再手动重复写一遍，是非常实用的语法糖。
但测试发现，该特性在搭配 ORDER BY 时，无法正确处理非默认等值语义，会直接返回错误的查询结果。要彻底修复需要重构查询优化器的相关逻辑，在 Beta 后期做这么大的改动风险不可控。社区最终选择回退，并计划在 PostgreSQL 20 中重新实现。
宁可回退，绝不带病发布：内核的质量红线
在外人看来，临到 Beta 阶段砍掉三大特性，像是开发进度失控。但对数据库行业的人来说，这恰恰是 PostgreSQL 最可靠的地方。
翻看 PostgreSQL 19 的开放问题列表就能明白，Beta 阶段依然有数十项核心问题待解决：REPACK 并发处理缺陷、逻辑复制竞态条件、事务隔离级别冲突、查询优化器结果错误…… 每一个都可能影响数据正确性或服务稳定性。
对于承载核心数据的数据库而言，正确性是不可妥协的底线。一个设计有缺陷的特性，上线后造成的可能是数据损坏、结果错误，甚至业务停摆。PostgreSQL 社区的准则从来都是：宁可不发布，也不发布有问题的功能。特性可以等下一个大版本，数据没有第二次机会。
AI 加速了找 bug，但加速不了内核开发
与新特性回退形成强烈对比的，是本次安全更新的 “高产”：
- 覆盖 14.24、15.19、16.15、17.11、18.6 全支持版本
- 一次性修复28 个安全漏洞，其中 10 余个 CVSS 3.1 评分高达 8.8 分
- 漏洞类型涵盖堆缓冲区溢出、整数环绕、类型混淆、SQL 注入、权限绕过，多数可直接用于执行任意代码
不可否认，AI 辅助的模糊测试、静态扫描、漏洞挖掘工具，正在大幅提升安全问题的发现效率。很多深层的边界场景、内存安全问题，过去需要几年才会暴露，现在可以被快速找到。从这个角度说，AI 确实加速了 “发现问题” 的速度。
但内核开发的核心，从来不是 “修 bug”，而是 “做对的设计”。 属性图的架构设计、分区语法的边界处理、GROUP BY 的语义兼容…… 这些都是工程设计层面的难题，需要资深开发者反复评审、多轮验证、兼容十几年的历史行为。这个严谨的工程过程，没有任何 AI 可以替代，也没有任何捷径可走。
AI 可以让漏洞更快浮出水面，但无法让内核更快变得成熟。 这就是为什么我们看到漏洞越修越快，但核心特性的迭代节奏，依然和二十年前一样稳健。
所有使用者必须关注的 4 个重点
除了特性回退，本次发布还有几个影响生产环境的关键信息，务必重视：
1. PostgreSQL 14 即将停止维护
PostgreSQL 14 将于2026 年 11 月 12 日正式 EOL，之后不再接收任何安全修复和 Bug 更新。如果你的生产环境还在运行 14 版本，建议立刻启动升级规划。
2. 全版本尽快升级安全补丁
本次修复的多个高危漏洞利用门槛低、影响范围广，涉及 psql 客户端、逻辑解码、正则函数、字符串处理等常用组件，所有生产环境都应尽快完成对应小版本升级。
3. 升级后务必检查这三类索引
本次更新修复了三个索引相关的严重问题，升级后需要针对性处理：
- 并行 GIN 索引构建可能导致
reltuples数值异常，造成 autovacuum 停止处理对应表，需检查并通过 ANALYZE 重置 btree_gist索引对浮点 NaN、bit 类型的处理存在错误，涉及相关列的索引建议重建ltree标签数超过约 14653 个时存在整数溢出，可能导致索引损坏，符合场景的索引建议重建
4. PG 19 Beta 3 仅限测试使用
PostgreSQL 19 目前仍处于 Beta 阶段，不建议用于生产环境。测试时请避开已回退的三个特性，不要基于它们做业务开发。根据社区路线图，Beta 4 将于 9 月 24 日发布，正式 GA 时间尚未确定。
结语
我们正处在一个所有人都在谈 “加速” 的时代，AI 好像能让一切都变快。 但 PostgreSQL 用一次 “反向更新” 提醒我们：越底层的基础软件，越不能急。
漏洞可以快速发现，但架构设计、正确性验证、兼容性打磨，必须一步一个脚印。回退三个特性，守住的是数据库最核心的可靠性；慢一个版本，换来的是几十年不变的信任。
对数据库来说，永远是：稳定先于特性，正确先于速度。 这大概就是 PostgreSQL 能够成为全球最受欢迎开源数据库的底层逻辑。
参考
PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released!
提交日志：https://git.postgresql.org/pg/commitdiff/3e8bcc8644feaa9ca1cc954197b6994817af4290
提交日志：https://git.postgresql.org/pg/commitdiff/2b9e1aff4d3d933ae8ee377fef22c2af9c7797e8
提交日志：https://git.postgresql.org/pg/commitdiff/372b8d1adb76740123791e9ded4f665b175f5bf5