PostgreSQL 19:REPACK、WAIT 和计划器终于可以被劝了
PostgreSQL 19 把 VACUUM FULL 与 CLUSTER 合并成 REPACK,加了等备库追平的 WAIT 命令,还给了两个能固定执行计划的扩展。这篇挑我真正关心的几条,顺带记下三个会咬人的不兼容改动。
PostgreSQL 19 的文档还在滚动更新(官方发布说明里日期仍写作待定),但「新特性概览」已经定型。几条我认为真正会改变日常操作的:
REPACK:VACUUM FULL 和 CLUSTER 合体
以前想回收磁盘空间得 VACUUM FULL,想按索引重排物理顺序得 CLUSTER,两个都要独占锁。19 把它们合并成一条 REPACK,而且给了 CONCURRENTLY 选项 —— 可以在不阻塞读写的情况下重排。
这条的意义不在语法变短,而在「重排大表」从必须停机变成可以挑时间。以前一张几百 GB 的表要 CLUSTER,基本等于宣布一次维护窗口。
WAIT:在备库上读到刚写的数据
主从架构里一直有个尴尬:写完主库立刻查备库,可能读不到。WAIT 命令让你等到某个备库把变更重放到指定位置再继续 —— 也就是在备库上实现「read-your-writes」。
这比「sleep 200ms 再查」强太多,也比把所有读都打到主库便宜。
计划器可以被固定下来了
新增两个扩展:pg_plan_advice 用来固定并控制查询计划器的决策,pg_stash_advice 则根据查询自动套用这些建议。
计划漂移是老问题了 —— 同一条 SQL 昨天走得很好,今天统计信息一更新就换了个灾难性的计划。以前只能靠 pg_hint_plan 这类第三方扩展或者改 SQL。现在核心给了官方手段。
复制与清理的改进
- 逻辑复制可以复制序列值了,并且在
wal_level = replica时不需要重启就能启用 - autovacuum 可以用并行 worker 清理索引,并且有了新的评分机制来决定先清理哪张表
- I/O worker 进程数自动伸缩,外键检查更快
「不需要重启」那条尤其实际:以前开逻辑复制要改 wal_level 并重启,在一台跑着业务的主库上,这是要排窗口的事。
三个会咬人的不兼容改动
升级前必须知道:
- 移除 RADIUS 支持。官方理由很直接:只支持 RADIUS over UDP,而这个组合「无法修复地不安全」。用 RADIUS 认证的要换方案。
standard_conforming_strings在服务端强制开启。用 19 之前的pg_dump导出、且原本是off的转储,无法正确导入 19 及以后。导出要用 19+ 的pg_dump。- 数据库名、角色名、表空间名不再允许回车和换行。
pg_upgrade会检查。
另外两个小变化:新增 password_expiration_warning_threshold(默认提前 7 天告警),以及 MD5 密码认证成功后会打警告(可用 md5_password_warnings 关掉)—— MD5 密码在 18 就被标记为弃用了。
我的判断
这四条里,REPACK ... CONCURRENTLY 和 WAIT 是能直接改变运维方式的;计划器建议扩展则是「终于不用装第三方」的补票。
但真正的风险在兼容性那三条。RADIUS 被删是因为它不安全 —— 这种「为了正确性主动删功能」的决定,PostgreSQL 一直做得比大多数项目果断。如果你的认证链路上有 RADIUS,这次升级不是「改天再说」的事。

评论
…