原文链接 https://www.bytebase.com/blog/postgres-19-features-im-excited-about
如果说 PostgreSQL 18 给数据库装上了「异步 I/O」这个新引擎,那 PostgreSQL 19 干的就是把整车的运维、监控、维护工具一起升级。
下面挑几个我觉得最值得讲的变化,聊聊它们到底解决了什么问题。
PostgreSQL 的查询规划器大多数时候很聪明,但偶尔也会犯傻。一旦犯傻,数据库就会跑出一个慢得离谱的执行计划,线上服务可能直接拖垮。
今年 2 月,Clerk 就栽过这么一个跟头:某一列的数据 99.9996% 都是 NULL,统计采样的时候恰好全采到了 NULL,于是规划器认定这一列「100% 是空的」,直接选了一个完全错误的执行计划,最后引发了一次线上故障。
过去遇到这种情况,要么改应用代码,要么装第三方扩展,各家方案五花八门。
PostgreSQL 19 把这件事正式收进了内核。新增的 pg_plan_advice 允许你给某条具体的查询写一份「建议」,告诉规划器:这条 SQL 应该走索引扫描,应该按什么顺序 JOIN。建议写一次,所有会话都生效,不用改任何业务代码。
这是 PostgreSQL 长期以来和 Oracle、SQL Server 之间一个明显差距,这次终于补上了第一块基石。
pg_get_database_ddl:一键导出 DDL
听起来不可思议,但 PostgreSQL 一直没有官方方法导出「创建数据库」、「创建角色」、「创建表空间」的 DDL 语句。每个团队都得自己拼,要么 shell 脚本包 pg_dump,要么手写目录查询。
PostgreSQL 19 给了三个开箱即用的函数:
SELECT pg_get_database_ddl('mydb'::regdatabase); SELECT pg_get_role_ddl('myrole'::regrole); SELECT pg_get_tablespace_ddl('mytbs');
迁移、审计、CI/CD 比对 schema,从此不用再造轮子。
REPACK CONCURRENTLY:在线重建表
两件过去必须「约维护窗口、提心吊胆做」的事情,现在可以在线做。
REPACK CONCURRENTLY:整理碎片化的表,过去要么锁表(VACUUM FULL),要么装第三方扩展 pg_repack。现在内核直接支持,业务读写不受影响。
校验和的开启/关闭:过去要停集群、跑工具、再启动。现在可以在运行中的集群里渐进式地切换。
对运维来说,这两项都把「高风险操作」降级成了「日常操作」。
pg_stat_lock & pg_stat_recovery:可观测性升级
锁:过去只能看「现在谁被卡住」,看不到「过去一段时间锁竞争集中在哪」。新视图 pg_stat_lock 把历史竞争数据完整暴露出来,大部分性能瓶颈往往就集中在两三张热点表上,有了这个视图,一查一个准。
备库:过去判断「主从延迟多少」得调用一堆函数再拼起来,而且每次调用拿到的是不同时刻的快照,经常误报。新视图 pg_stat_recovery 一次性返回所有状态,主从监控终于变得可靠。
逻辑复制能复制表的数据,但不复制 SERIAL、IDENTITY 这类自增列背后的「序列号」。结果就是:把订阅库切换成主库后,下一条 INSERT 直接主键冲突,因为新主库不知道序列已经走到哪儿了。
PostgreSQL 19 修了这个坑。做主从切换、零停机升级时更安全了,但要注意:序列只在你执行REFRESH SEQUENCES 时同步一次,所以记得把这一步写进切换流程的最后。
PostgreSQL 在管理「行级锁共享」时用了一个叫 MultiXact 的内部结构,过去它有一个 32 位上限,大约 40 亿。听起来很多,但在高并发 + 外键密集的业务里,几天就能耗尽。一旦耗尽,数据库就锁死,只能紧急停机抢救。
去年 5 月,Metronome 就在一次数据迁移中连续遇到 4 次这种故障,在 30TB 的集群上做了好几个小时的紧急 vacuum 才恢复。
这个上限不是日常监控能看到的——大多数 DBA 根本不知道有这个东西,直到爆炸的那一刻。
PostgreSQL 19 把它加宽到 64 位,这个隐患被彻底消除,不是缓解,是消除。
熟悉 PostgreSQL 的人都知道 vacuum 是个甩不掉的老朋友。19 版本里,autovacuum 终于可以并行处理索引,大表清理速度直接上一个台阶。
更重要的是,过去 autovacuum 像个黑盒子:为什么这张表先清?为什么它跑这么慢?都得靠猜。19 把这些信息全暴露在系统视图里:优先级怎么算的、计划用几个并行 worker、实际启动了几个、是不是进入了紧急模式——一目了然。
调优从「改参数 + 祈祷」变成了「看数据 + 决策」。
这一版里,pg_plan_advice 是我最兴奋的特性。它本身只是一个钩子,但它给社区铺好了路:未来可以在它之上,做出像 Oracle SPM 那样的「自动基线 + 计划演化 + 回归检测」系统,而这是 PostgreSQL 用户多年来一直眼馋的能力。
其他特性看起来零碎,但都是「长期被坑、终于解决」的那种。Vacuum 和 MultiXact 这俩老问题,本质上都源于 PostgreSQL 实现 MVCC 的那个经典选择——把每个被更新的行都保留一个旧版本,再用后台进程慢慢清。在新一代存储引擎(比如 OrioleDB)进入内核之前,我们恐怕还得继续打补丁,但每打一个,生产环境就轻松一点。
PostgreSQL 19 发布说明草案https://www.postgresql.org/docs/devel/release-19.html
Clerk 2026 年 2 月故障复盘 https://clerk.com/blog/2026-02-19-system-outage-postmortem
Metronome 2025 年 5 月 MultiXact 耗尽事件复盘 https://metronome.com/blog/root-cause-analysis-postgresql-multixact-member-exhaustion-incidents-may-2025
论文《The Part of PostgreSQL We Hate the Most》(讲 MVCC 的代价) https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html
版权申明：内容来源网络，版权归原创者所有，如有侵权请联系删除
想了解更多行业资讯
扫码关注👇
了解更多考试相关
扫码添加上智启元官方客服微信👇
17认证网
