PostgreSQL迁移时pg_dump/pg_restore应匹配源端还是目标端？

基础兼容性硬红线 #

• pg_dump 本身支持向后连接版本更低的源端PostgreSQL服务，但存在不可突破的硬限制：pg_dump的版本，绝对不能高于你后续要恢复的目标端PostgreSQL版本。
• 你用12.2版本的pg_dump导出9.6版本源端的流程，本身是允许的（12.2 > 9.6，符合向后连接的要求），但后续要往11版本的Azure PostgreSQL上恢复时，就踩了硬红线：12.2版本导出的自定义格式dump，会携带12版本专属的对象元数据、新语法、系统目录结构，比它版本低的11版本pg_restore根本无法解析这些新增结构，自然会迁移失败。

关于“理想匹配目标端”说法的适用边界 #

• 大家常说的“pg_dump/pg_restore理想状态下要匹配目标端版本”，是有前提条件的：源端PostgreSQL的版本，必须低于或等于目标端版本。
• 举你当前的场景为例：源是9.6、目标是11，这种场景下最理想的配置确实是使用11.x版本的pg_dump/pg_restore连接9.6的源端导出，再向11的目标端导入——导出的内容完全匹配11版本目标端的解析逻辑，没有多余的高版本冗余结构，恢复效率和兼容性都是最优的。
• 这个规则不是绝对通用的，如果你的pg_dump版本比目标端高，哪怕能正常连接源端、能顺利导出文件，最终的恢复流程也必然会失败，和你源端是什么版本没有关系。

你当前场景下的可选可靠方案 #

• 方案1（最优）：下载和Azure PostgreSQL 11完全匹配的pg_dump/pg_restore工具版本，替换当前的12.2版本工具执行迁移。
• 方案2（已验证可行）：沿用同组开发使用的9.6版本工具完成迁移。因为9.6版本导出的dump只包含9.6版本支持的对象定义，向更高版本的11目标端恢复时，不会出现跨高版本的元数据不兼容问题，是找不到匹配目标端工具时的可靠备选。

常见认知误区 #

• 很多人误以为pg_dump连接源端时版本越新越好，实际上只要导出的dump要往比工具版本旧的目标端恢复，再新的pg_dump导出的文件都无法正常解析——版本错位的风险完全出在恢复环节，和导出环节能不能连上源端没有关系。

内容的提问来源于stack exchange，提问作者user15360876