PostgreSQL 19 定了 11 月 19 日 GA：pg_plan_advice 与并行 autovacuum 上线，SQL/PGQ 被撤回
PostgreSQL 19 的时间表终于钉死了：GA 定在 2026 年 11 月 19 日。10 月 15 日的 RC 1 公告里，这个日期第一次出现在官方发布通告里；11 月 12 日的 RC 2 公告再次确认——除非再发现需要延期的严重问题，否则 11 月 19 日正式发布。
同一个 11 月 12 日，PostgreSQL 项目组还一口气更新了全部在支持版本：18.7、17.12、16.16、15.20、14.25，加上 19 的 RC 2。官方公告写得很直白：这一次修复了 52 个安全漏洞和 140 多个 bug。而 14.25 是 PostgreSQL 14 的最后一个版本，这个大版本从此 EOL。
这大概是 2026 年下半年数据库圈最值得盯的一次发布，原因不在于新特性清单有多长，而在于它把「PostgreSQL 项目组现在怎么决定什么能进大版本」这件事摆到了台面上。
一次发布，五套维护版本，52 个 CVE
先看安全面的实际体量。我把官方安全页面（postgresql.org/support/security/）里「Fixed in 18.7 / 17.12 / 16.16 / 15.20 / 14.25」这一批的 52 条 CVE 逐条统计了一遍：
| CVSS v3.1 区间 | 数量 | 占比 |
|---|---|---|
| 严重（8.0–8.8） | 35 | 约 67% |
| 高危（7.0–7.9） | 3 | 约 6% |
| 中危（4.0–6.9） | 12 | 约 23% |
| 低危（<4.0） | 2 | 约 4% |
按组件拆：core server 43 条、client 6 条、contrib module 3 条。最高分是 8.8，没有 9.0 及以上的条目。受影响版本上，40 条同时影响 18/17/16/15/14 五个分支，另有 5 条只影响 18、4 条影响 18 和 17、2 条影响 18/17/16、1 条影响 18/17/16/15。
这个分布有个很直接的运维含义：这批补丁不是「19 的专属问题」，而是横穿所有在支持分支的共性修复。如果你的集群还停在 16.x 或 17.x，这 52 个 CVE 跟你直接相关。
从修复项本身看，这批 CVE 的主题高度集中在类型混淆与 use-after-free：plpgsql 记录字段类型混淆、plperl 各种 reentrant 转换、tsvector_delete() 堆溢出、ts_rank_cd() 堆溢出、extended-statistics 伪类型混淆、扩展脚本 schema 处理不当导致的任意 SQL 执行。另外还有几个值得单独盯的：pg_dump / pg_restore / reindexdb 的命令注入与归档校验缺失、logical replication 可以写到订阅端系统表、dblink 与 subscriptions 可向任意文件追加内容。
被撤回的特性：一次集中手术
19 版本不是按原计划交付的。官方 Beta 4 公告（2026-09-24）里明确写着这一版 reverted several features，列出的撤回清单包括：
| 被撤回的变更 | 官方说明 |
|---|---|
| SQL/PGQ（属性图查询）支持 | 整体撤回，图查询能力顺延至 PostgreSQL 20 |
| 在线启停数据校验和（data checksums） | 撤回在线开关相关改动 |
FOR PORTION OF 时态更新/删除 |
撤回 |
ALTER TABLE ... MERGE PARTITIONS / SPLIT PARTITIONS |
撤回 |
pg_get_role_ddl() / pg_get_tablespace_ddl() / pg_get_database_ddl() |
直接移除三个函数 |
postmaster 强制 LC_COLLATE=C 的改动 |
撤回 |
Snowflake 工程团队在其官方账号上给出的统计是：自 beta 开始以来累计 53 项变更被撤回，其中点名 SQL/PGQ 已成 PostgreSQL 20 的材料、ALTER TABLE MERGE/SPLIT PARTITION 已撤回、GROUP BY ALL 因可能产生错误结果而被撤下。Snowflake 自己的建议很务实：「PostgreSQL 18 今天仍是安全的升级目标。」
另外两位核心开发者的解释，把「为什么撤回」这件事拆得更清楚。Robert Haas 给出的硬数据是同一时间窗（4 月 8 日特性冻结到 9 月 25 日）内的提交量变化：
| 分支 | 2025 年 | 2026 年 | 变化 |
|---|---|---|---|
master（仅进主干） |
1,037 | 1,443 | +39% |
| 在研稳定分支（REL_18 → REL_19） | 724 | 1,169 | +60% 以上 |
| 上一个稳定分支（REL_17 → REL_18） | 248 | 433 | +74% 以上 |
Haas 强调的是增长结构：真正暴增的是回补提交，而只进主干的净提交实际略有下降。原因是「现在有海量的人在用 LLM 找 PostgreSQL 的 bug 并提交报告」——LLM 能很快找到问题，但产出的补丁不一定正确、不一定符合 PostgreSQL 的代码规范，仍然得由人来评审和提交，而这些人在 2025 到 2026 年之间并没有变聪明。评审本该用于检查新特性代码的时间，被安全问题和旧分支 bug 分走了。
图：同一时间窗内三个分支的提交量变化（数据取自 Robert Haas 博客，本文整理绘制）
Peter Eisentraut 的补充解释则指向三件事：一是 LLM 辅助评审抬高了有效质量门槛——这些特性写于 LLM 评审还不实用的年代，等于在提交之后被换了一把更严的尺子；二是 Vulnpocalypse（4 月到 8 月密集的安全修复）让资深开发者整段时间都在处理安全问题，beta 期本该有的额外评审与测试被压缩，因此大量问题在 beta 后期才暴露；三是部分特性本身架构复杂、缺少脚手架，像 Eisentraut 举的那个例子——一个 SQL 特性要同时正确处理 domain、复合类型上的 domain、分区分离重挂、security-definer 函数里的视图等组合，人工无法穷举，但 LLM 辅助模糊测试可以很快翻出来。
他也给出了社区正在考虑的解法方向：给特性加一种「experimental」状态先合入、再在主干里慢慢成熟。他还提到 REPACK CONCURRENTLY、序列的逻辑复制、以及基于 pg_plan_advice 的计划器提示，都在这次撤回潮中幸存了下来。
19 真正留下来的新东西
按官方 release notes（文档标注为 AS OF 2026-10-09），19 的新特性大致可以分成四类。
空间与计划器控制是这版最实质的变化：
| 特性 | 说明 |
|---|---|
REPACK / REPACK (CONCURRENTLY) |
新的重建表命令，回收空间并重排表内容；CONCURRENTLY 变体不阻塞读写，同期新增了 max_repack_replication_slots 变量 |
pg_plan_advice 扩展 |
直接控制计划器决策 |
pg_stash_advice 扩展 |
按 query id 指定计划建议并自动应用 |
| 并行 autovacuum | autovacuum_max_parallel_workers 控制总数，表级 autovacuum_parallel_workers 控制单表 |
| autovacuum 评分体系 | 新增 5 个权重变量：autovacuum_freeze_score_weight、autovacuum_multixact_freeze_score_weight、autovacuum_vacuum_score_weight、autovacuum_vacuum_insert_score_weight、autovacuum_analyze_score_weight，决定表的处理优先级 |
io_method = worker |
I/O worker 数量按需自动伸缩 |
复制与一致性方面，19 让逻辑复制更自洽：可以在 wal_level = replica 时按需自动启用逻辑复制，不再需要重启改配置；新增只读的 effective_wal_level 变量以及 pg_controldata 应用、pg_control_checkpoint() 函数来报告实际生效的 WAL 级别；序列也可以进逻辑复制了（CREATE PUBLICATION ... ALL SEQUENCES，订阅端用 ALTER SUBSCRIPTION ... REFRESH SEQUENCES 同步序列存在性）。另外 standby 上新增 WAIT 命令，实现「read-your-writes」一致性。
可观测性新增了几个系统视图：pg_stat_lock（按锁类型统计）、pg_stat_recovery（恢复状态）、pg_stat_autovacuum_scores（逐表 autovacuum 明细）、pg_stat_progress_repack（同时覆盖 REPACK、CLUSTER、VACUUM FULL 的进度），pg_stat_progress_vacuum 与 pg_stat_progress_analyze 也增加了 started_by（发起方）和 mode（激进程度）两列。
数据与 SQL 细节上，COPY TO 支持输出 JSON（还能用 FORCE_ARRAY 输出单个 JSON 数组），COPY FROM 支持 ON_ERROR SET_NULL 把非法输入置空而不是报错，INSERT ... ON CONFLICT DO SELECT ... RETURNING 让冲突行也能返回，窗口函数支持 IGNORE NULLS / RESPECT NULLS（适用 lead()、lag()、first_value()、last_value()、nth_value()），新增 64 位无符号类型 oid8，以及 EXPLAIN 增加了 I/O 与 WAL 统计输出。
还有两个容易被忽略但对运维很实用的东西：服务端支持 SNI（Server Name Indication），配合新增的 PGDATA/pg_hosts.conf 配置文件；以及 pg_hba.conf 支持注册自定义 OAuth validator。
RC 2 相对 RC 1 的修复清单里，有几条是直接影响升级的。最要紧的是回退了 JSON_ARRAY() / JSON_OBJECT() 表达式用于表达式索引、生成列和分区键的改动（这类索引可能过期）——官方明确要求：测试期间建过这类对象的，必须在升级前 drop 或重新定义，否则 pg_dump/pg_restore 和 pg_upgrade 都会失败。另外还修了 GROUPING SETS 查询返回错误结果、first_value()/nth_value() 配合 IGNORE NULLS 与某些 EXCLUDE 帧选项时的死循环、eager aggregation 在 join 条件里对 volatile 函数的调用次数错误（每组一次而非每行一次）、以及 standby 提升时可能无限等待的问题。
升级前必须过一遍的 8 项默认变更（官方不兼容清单有 20+ 条）
大版本升级的痛苦从来不在新特性，而在默认行为悄悄变了。19 的 release notes 里专门有一节列出了不兼容变更，完整清单有 20 多条，下面这 8 条是其中对运维影响最大、最容易被忽略的，值得逐条对照自己的配置：
| 变更项 | 变化 | 对运维的实际影响 |
|---|---|---|
standard_conforming_strings |
强制为 on | 19 之前用 pg_dump/pg_dumpall 且该选项为 off 的 dump 文件将无法加载 |
max_locks_per_transaction |
默认 64 → 128 | 锁容量实质翻倍；锁大小分配方式变了，要匹配以前的容量得按老值配 |
| JIT | 默认关闭 | 此前按优化器成本自动启用；大型分析型查询需要手动打开 |
inet / cidr 默认索引 opclass |
btree_gist → GiST |
原 btree_gist 的 inet/cidr opclass 是坏的（会漏掉本该返回的行）；pg_upgrade 会拒绝升级含此类索引的集群 |
| RADIUS 认证 | 移除 | PostgreSQL 只支持 UDP 下的 RADIUS，本身不可安全修复 |
| MD5 口令 | 18 已弃用；19 在登录成功后告警 | 可用 md5_password_warnings 关闭（该告警没有固定周期）；另一个容易混淆的参数是 password_expiration_warning_threshold，它的默认警告期是 7 天，属于口令过期告警，与 MD5 告警是两回事 |
全文本搜索 / pg_trgm |
改用数据库 locale provider 做字符分类 | 升级后建议重建相关索引并重算已存的 tsvector |
log_lock_waits |
默认开启 | 锁等待日志从可选项变成默认项，日志量会涨 |
还有一条是 pg_upgrade 会直接挡住你的：inet/cidr 上使用 btree_gist opclass 的集群，pg_upgrade 拒绝升级，必须先处理掉这些索引。
对国内团队意味着什么
把上面的信息放到国内团队的语境里，有几件事值得单独拿出来说。
第一，PostgreSQL 14 已经 EOL。11 月 12 日的 14.25 是它的最后一版，之后不再有安全修复和 bug 修复。如果你的生产环境还有 14，这一批 52 个 CVE 是最后的机会窗口——下一批就没人修了。这一条的时间压力比 19 的 GA 更紧迫。
第二，国产数据库替换潮里，PostgreSQL 内核系（TiDB、OceanBase 的 PG 兼容模式、各种基于 PG 的国产发行版）的用户同样要关注内核版本节奏，但需要注意 19 的破坏性变更在下游发行版上的落地时间通常滞后于上游。别把上游 RC 当成生产可用版本去赌。
第三，LLM 找 bug 这件事对国内自研数据库同样成立。Haas 那组提交量数据本质上是在说：当你的用户群里有大量用 AI 工具做代码审查、自动化 fuzz 的人时，你的回补成本会显著上升，而不是你的开发效率下降。国内数据库团队如果也在用 AI 辅助开发自己的内核，值得把这组数据当成容量规划的输入。
第四，关于 pg_plan_advice 这类「计划器提示」机制——它和国内团队熟悉的各种 SQL 改写、hint 注入方案是同一类工具，19 把它做进了内核，值得在升级评估时和现有的 hint 方案做一次成本对比。
小夏点评
一、这次延期的性质，和「开发进度落后」完全不是一回事。 PostgreSQL 19 迟到六周，是因为它在 beta 后期集中撤回了一批已经写完、测过的特性——包括 SQL/PGQ 这种本该是 19 年头牌的图查询能力。Eisentraut 说得很清楚：这些代码是很多年前写的，那时还没有 LLM 辅助评审，提交之后再被换了一把更严的尺子。Robert Haas 的提交量数据也印证了同一件事——暴增的是回补提交，不是新特性代码。这对读者的启示是：不要把「PostgreSQL 19 延期」读成「PostgreSQL 团队效率下降」。读成「PostgreSQL 团队不愿意把没准备好五年之内的东西塞进大版本」更接近事实。顺带说，这轮延期也直接验证了项目组公告里写的那条原则——「首先，PostgreSQL 必须是可靠的；此外，社区追求可预测的发布时间表。」 这两条在延期面前被同时兑现了。
二、这批更新里最该警惕的不是分数最高的那些，而是「修复方式改变了数据可信度」的那几条。 严重度评分告诉你的是「攻击者能造成多大损害」，但同批更新里有一批条目的真实风险在别处：RC 2 修了 GROUPING SETS 查询返回错误结果（结果错了但不报错）、修了 eager aggregation 对 volatile 函数的调用次数错误（同样是不报错的错误结果），而 11 月 12 日这批补丁修了 tsvector_delete() 和 ts_rank_cd() 的堆溢出、修了 extended-statistics 伪类型混淆、以及 pg_dump/pg_restore/reindexdb 的命令注入。这些属于「你的数据库一直在安静地返回错误答案」那一类。实务上：升级前先做一次结果一致性对拍，拿核心报表 SQL 在 18.7 与 19 上跑同样的数据集比对输出——尤其是带 GROUPING SETS、窗口函数、统计信息扩展的查询。升级后至少跑一次 REINDEX 处理 FTS/pg_trgm 相关索引并重算 tsvector，官方为此专门写了指引。
三、给国内 IT 运维与开发者的具体启示：这次 GA 的真实优先级排序是「先把 14 迁走，再考虑 19」，而 19 的升级门槛不在新特性，在那张默认变更表。 拆成三条可执行的：第一，把 14.25 当作硬截止线——它之后再无安全补丁，把「生产环境仍在跑 14」这件事从技术债台账挪到安全台账，按业务系统的重要性排迁移序，优先跑 inet/cidr 上带 btree_gist 索引的集群（这类 pg_upgrade 会直接拒绝，是最容易卡住的一批）；第二，建一张自己的「19 默认变更对照表」，把 release notes 不兼容清单里本文列出的那 8 项逐条映射到自己的 postgresql.conf 与运维脚本上，重点是 standard_conforming_strings（会导致老 dump 无法加载）、JIT 默认关闭（会悄悄改变分析型查询的执行计划，可能让原本秒级的大查询变成分钟级）、max_locks_per_transaction 翻倍（共享内存规划要重算）以及 log_lock_waits 默认开启（日志量上涨，需要提前调整 logrotate 策略）；第三，把 pg_plan_advice / pg_stash_advice 当成升级后的第一批优化抓手——19 既然把计划器建议做进了内核，那些长期靠 SQL 改写或 hint 注入硬撑的慢查询，值得在新版本上做一次重新评估，看能不能把「改写 SQL」换成「声明式计划建议」，这在多副本、参数各异的国内业务环境里可维护性差别很大。
参考链接
- – 官方发布通告：PostgreSQL 18.7, 17.12, 16.16, 15.20, 14.25, and 19 RC 2 Released!（2026-11-12）https://www.postgresql.org/about/news/postgresql-187-1712-1616-1520-1425-and-19-rc-2-released-3442/
- – 官方发布通告：PostgreSQL 19 RC 1 Released!（2026-10-15）https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/
- – 官方发布通告：PostgreSQL 19 Beta 4 Released!（2026-09-24，撤回特性清单出处）https://www.postgresql.org/about/news/postgresql-19-beta-4-released-3386/
- – 官方安全信息页（52 条 CVE 的 CVSS 分值与受影响版本统计口径）https://www.postgresql.org/support/security/
- – 官方 Release Notes：PostgreSQL 19（文档标注 AS OF 2026-10-09）https://www.postgresql.org/docs/19/release-19.html
- – 官方版本支持策略（PostgreSQL 14 EOL）https://www.postgresql.org/support/versioning/
- – 核心开发者说明：Peter Eisentraut《The reverts will continue until morale improves》（2026-10-09）http://peter.eisentraut.org/blog/2026/10/09/the-reverts-will-continue-until-morale-improves
- – 核心开发者说明：Robert Haas《Postgres 19 is late, and it’s AI’s fault》（提交量数据出处）http://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html
- – 业界观察：Snowflake Developers《PostgreSQL 19 Delayed Due to Design Flaws and Issues》（53 项撤回统计与升级建议；官方博客原文页返回 403，此处为其官方账号发布稿）https://www.linkedin.com/posts/snowflake-developers_postgresql-19-is-delayed-thats-the-release-activity-7508903165816127488-epJ7
- – 业界观察：Snowflake Engineering Blog《PostgreSQL 19 Delayed: Key Feature Reversions & Release Updates》（同一篇分析的官方博客版，含 PG18/PG19 撤回项对照；页面直接抓取返回 403，故正文数据以官方账号发布稿为准）https://www.snowflake.com/en/blog/engineering/postgresql-19-release-delay-feature-reverts
- – 图片素材：PostgreSQL 官方标识 elephant.png https://www.postgresql.org/media/img/about/press/elephant.png
