PostgreSQL 13迁移至15远程服务器后SQL报错，求正确迁移方法

问题分析 #

你遇到的$3ORDER BY语法错误，是因为存储过程/自定义函数中的SQL代码在纯文本备份恢复时丢失了空格。默认的纯文本pg_dump输出在某些场景下（比如函数内的紧凑SQL）可能会出现格式解析异常，导致参数占位符与关键字粘连。

正确迁移步骤 #

1. 使用自定义格式备份源数据库 #

放弃纯文本备份，改用PostgreSQL的自定义格式，它能精准保留所有数据库对象的结构细节：

pg_dump -h 192.168.8.2 -p 5433 -U postgres -d db -F c -f db.dump

• -F c指定自定义格式，比纯文本更可靠，避免语法格式丢失。

2. 在目标服务器恢复备份 #

先创建空数据库（如果还没创建）：

createdb -U postgres db

然后用pg_restore恢复自定义格式备份：

pg_restore -U postgres -d db db.dump > restore.log

pg_restore会严格解析备份中的对象定义，不会出现纯文本恢复时的格式丢失问题。

3. 迁移前的兼容性检查 #

• 提前在源服务器执行兼容性检查（如果条件允许）：

  pg_upgrade --check -b /path/to/pg13/bin -B /path/to/pg15/bin -d /path/to/pg13/data -D /path/to/pg15/data
  

• 确认目标服务器安装了源数据库依赖的所有扩展（如pg_trgm、PostGIS等）
• 导出源数据库的 schema 单独测试：

  pg_dump -h 192.168.8.2 -p 5433 -U postgres -d db --schema-only -f schema.sql
  

  在目标服务器上执行psql -U postgres -d db -f schema.sql，提前发现语法兼容性问题。

4. 当前错误的临时修复 #

如果需要快速解决当前问题，找到对应的存储过程/函数，手动修正SQL语句中的$3ORDER BY为$3 ORDER BY，重新创建函数即可。但这只是临时方案，建议用自定义格式重新迁移避免后续问题。

注意事项 #

• 复杂数据库（含大量自定义函数、触发器、存储过程）禁止用纯文本格式备份，自定义格式是首选。
• 迁移完成后，务必测试核心业务逻辑，验证所有数据库对象的功能正常。
• 查阅官方文档了解PG13到15的版本差异，提前规避潜在的兼容性风险。

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