PostgreSQL 19 计划 10 月 15 日出 RC1，10 月 29 日 GA。功能之外，更该关心的是那份不兼容清单。下面几条是最容易在小型 SaaS 上引爆的。
JIT 默认关闭
这一条不会报错，只会变慢。跑大分析查询的团队会发现夜间报表时间变长，而且很难联想到是升级导致的。做法是升级前把最慢的十条查询计时存下来，升级后再跑一遍对比。确认 JIT 确实有收益，再单独打开。
standard_conforming_strings 强制开启
影响用反斜杠转义的老旧代码和旧版本导出的转储文件。用 PG 19 的 pg_dump 重新导出，或者在导出时把这个设置打开。这个问题在恢复阶段才暴露，是最糟糕的时机。
max_locks_per_transaction 从 64 改到 128
听起来是好事，但如果你几年前为大分区表把这个值调过，沿用旧数字反而只剩一半容量。后果是负载上来时报共享内存不足。检查一下这个值，需要的话翻倍。
json_array() 空结果返回空数组
以前返回 NULL，现在返回空数组。如果你的代码把 NULL 当作“无数据”，空数组会被当成“有数据”，逻辑分支就错了。全局搜一下这个函数的调用点。
postgres_fdw 传递 READ ONLY
只读事务里通过外部表的写入会直接失败。
RADIUS 认证移除、MULE_INTERNAL 编码移除
命中率低但一旦命中就是致命的。升级前检查 pg_hba.conf 和数据库编码。
新东西里最实用的两个
REPACK 把 VACUUM FULL 和 CLUSTER 合成一条命令，还能 CONCURRENTLY 不阻塞读写，以前要靠 pg_repack 扩展。WAIT 命令可以等到备库追平某个点，实现读己之写，不用在应用代码里 sleep。
升级路径建议
不要碰生产。先起一个 RC 实例，跑 pg_upgrade --check，用 PG 19 的 pg_dump 导出，跑测试套件，再回放一天的慢查询日志。旧集群至少保留一个完整业务周期——月末出账这类批量任务最容易藏问题。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。