在数据库运维中，将PostgreSQL从低版本迁移到高版本是常见任务，而pg_dump与pg_restore作为官方提供的逻辑备份恢复工具，其跨版本行为直接影响迁移成败。很多故障并不是数据损坏，而是工具链版本错配导致恢复中断。要保障兼容性，必须先理解这两个工具在跨版本场景下的设计边界与执行逻辑。
pg_dump与pg_restore的版本匹配基本原则
PostgreSQL官方明确规定：pg_dump可以连接比自身版本旧的服务器进行导出，但不能连接比自身新的服务器；pg_restore必须与生成归档的pg_dump主版本保持一致，或略高。也就是说，如果你要把PostgreSQL 11的库迁移到PostgreSQL 14，最安全的做法是使用14自带的pg_dump去连接11的库，导出custom或directory格式的备份，再用14的pg_restore恢复到14实例。这样导出的定义语句已经按照目标版本语法生成，避免了恢复时解析旧语法的问题。
反过来，如果使用11的pg_dump去导出14的库，工具会直接报错拒绝连接。即便某些小版本间允许，也不推荐，因为新版本引入的数据类型或系统函数可能无法被旧工具正确表述。在自动化脚本中，常常有人写死使用系统默认pg_dump，当源和目标不在同一台机器且版本不同时，就会踩坑。建议迁移前用pg_dump --version与psql --version确认工具链，并在文档中记录对应服务器大版本。
除了主版本，小版本之间一般向前兼容。例如14.2的pg_dump可以导出14.5的库并由14.5的pg_restore恢复，但依然推荐以目标实例的大版本工具为准。对于长期维护多个集群的团队，可以准备一个包含各版本客户端的容器镜像，按迁移需求切换，避免主机全局安装造成冲突。
跨版本导出时的常见不兼容点与应对
实际跨版本迁移里，最容易出问题的是对象定义层面。比如PostgreSQL 12之前，分区表实现依赖表继承与触发器，而12之后改为内置声明式分区。如果用12以后的pg_dump导出10的库，会自动转换为新语法；但若反向操作则不可能。另外，系统函数如pg_get_expr的返回值细节、生成列（generated column）在11才引入，旧版工具遇到这种列会直接忽略或报错，导致恢复后表结构缺失。
另一个隐蔽问题是扩展（extension）。PostgreSQL的postgis、pg_stat_statements等扩展在不同版本中提供的函数签名可能变化。用目标版pg_dump导出时，它会记录扩展版本号，恢复端必须安装相同或兼容版本，否则pg_restore执行CREATE EXTENSION会失败。此时应先在目标库手动创建扩展再导入数据，或利用--no-owner与--section参数分段恢复，跳过易错的定义段后单独处理。
对于大型库，建议使用directory格式加并行导出：pg_dump -Fd -j 8 -f /backup/db，这样既能利用多核，也方便用pg_restore的-j并行恢复。若遇到某张表因类型不兼容卡住，可先排除该表，恢复其余数据后再用--table单独处理。下面示例展示用目标版本工具导出的标准命令：
# 使用PG14客户端导出PG11库 pg_dump -h 192.168.0.1 -p 5432 -U backup -F c -b -v -f pg11_to_14.dump postgres # 在PG14实例恢复 pg_restore -h 127.0.0.1 -p 5432 -U restore -C -d postgres pg11_to_14.dump
制定稳妥的跨版本迁移操作流程
基于上述原理，可总结出一套可复用流程。第一步，在目标服务器安装与待升级至版本一致的PostgreSQL客户端工具包；第二步，用该包中的pg_dump连接源库做全量逻辑备份，优先选custom或directory格式以保留可并行与选择性恢复能力；第三步，在目标库初始化空实例，创建对应角色与表空间，注意密码与权限映射；第四步，执行pg_restore并观察日志，对报错扩展或函数做手工修正；第五步，校验行数、序列值与约束，完成切割。
若环境限制只能使用源库旧版工具，且目标版本跨度大于一个主版本，应采用逐级中转。例如从9.6升到15，可先升到12，再用12工具升到15。每级之间执行ANALYZE与REINDEX，防止统计信息丢失引发性能退化。此方式虽繁琐，但能规避直接跨多版带来的语法断层。下表对比两种策略差异：
| 策略 | 工具来源 | 风险 | 适用场景 |
|---|---|---|---|
| 目标版直导 | 目标库自带pg_dump | 低，官方推荐 | 网络可达源库 |
| 旧版中转 | 源库旧pg_dump | 高，需多级 | 隔离环境无法装新客户端 |
最后强调，任何跨版本操作前都必须做本地演练。用影子库跑通导出恢复全流程，记录耗时与错误，才能在生产窗口内可控执行。逻辑备份不等于物理复制，它给了你重写对象定义的机会，也要求你主动处理版本差异，而不是指望工具 silently 兼容。
pg_dumppg_restorePostgreSQL_cross_version修改时间：2026-08-16 19:44:32