升级PostgreSQL 19先查什么？五项准备与验收要求

升级时最难受的情况，是新数据库已经启动，应用却进不去，或直到跑报表、恢复备份和主备切换才发现异常。准备升19，需要把业务整条链路验证一遍，启动成功不能算结束。

这五项可作为上线检查清单，每项都要有执行结果、测试记录或恢复用时。“理论上兼容”还不足以作为通过依据。

第一件：确认版本和扩展真的能一起工作

先核实实际服务端版本，再逐个业务库列出扩展。一个实例有多个数据库时，不要只检查默认数据库：

把这些结果与新环境逐项对照：扩展有没有支持 19 的安装包，是否需要更新，是否有专门的升级步骤。涉及 C 语言模块的扩展，旧版本文件通常不能直接复制给新主版本使用。

还要测试应用驱动、连接池、定时任务和管理工具。网页程序能连库，不代表夜间导出脚本、旧报表工具也能连接。通过标准是：所有实际使用的客户端，都在新环境完成过一次对应操作。

第二件：检查会改变旧行为的设置和对象

优先检查 19 中变化较大的地方：RADIUS 认证已移除；字符串设置 standard_conforming_strings 强制开启；JIT 默认关闭；旧的 inet/cidr btree_gist 索引可能阻止 pg_upgrade；监控视图中也有字段和等待事件名称变化。

这些问题不能靠一份参数文件原样复制解决。尤其是字符串处理，既要检查数据库设置，也要搜索程序和备份脚本是否显式设置 off，或者依赖普通字符串里的反斜杠转义。

若从 17 直接升 19，还要阅读 18 的兼容性变化。跨版本升级可以省一次迁移，却不能跳过中间版本改变了什么。

第三件：备份必须真的恢复过

备份任务显示成功，只能证明文件生成了，不证明能完整恢复。应在独立环境恢复一份接近生产的备份，检查角色、权限、扩展、表结构和数据，并运行几条关键业务查询。

如果准备做 pg_upgrade，要保留能够独立恢复旧库的备份。使用 link 或 swap 等模式前，先弄清旧数据目录是否还可单独使用。不能把一个已经被新库共用或改动的目录，误认为随时能启动的退路。

通过标准是：有人按写好的步骤成功恢复过，并记录花了多久。如果恢复需要两小时，升级计划里就不能写“十分钟内回退完成”。

第四件：把升级完整演练一遍

使用与生产接近的数据规模、扩展和配置执行演练。如果采用 pg_upgrade，先跑目标版本的 --check，再做一次实际迁移；若采用导出恢复，要把创建索引、校验约束和收集统计信息的时间算进去。

只查 --check 通过还不够，它不能证明所有业务 SQL、第三方扩展和程序逻辑都正常。演练要一直做到应用启动、典型业务完成、备份恢复可用。

演练时还应记录磁盘最高占用、WAL 产生量、备库追赶时间，以及业务必须停止写入多久。真正的维护窗口，是整个切换过程的时间，不只是升级命令运行的时间。

第五件：写清切换条件和失败处理

先明确旧端何时停写、怎样确认最后修改已到新端，以及何时开放新库。如果新库已收到新数据，又准备退回旧库，数据差异该怎样处理，也要提前决定。

验收可以分为数据、业务和运维三组：关键表与汇总要核对，登录读写和后台任务要跑通，监控告警、复制归档及新备份也要检查。

这五项提前完成，许多问题就能在切换前安排处理。比起列很多参数，能证明数据可迁、业务可运行、异常可恢复的演练记录更有用。