我的开发机器（称之为D）运行PostgreSQL 9.4.5。我的生产机器（称之为P）运行PostgreSQL 8.4.20。
我没有使用PostgreSQL 9.x中的任何新功能或类型。
有时我需要反映D上P的状态，有时候我需要做相反的事情。在这两种情况下，我都使用pg_dump / pg_restore。
当我从P转储恢复到D时，我从未遇到任何错误或警告。但是，当我做相反的操作时，我会收到多个unrecognized configuration parameter "lock_timeout"错误。我知道这个配置参数是在9.3中引入的，并且由于其余的恢复过程正常，我只是忽略了错误消息。
我的问题是：在不同的主要版本中使用pg_dump / pg_restore是不是一个坏主意，或者可以安全地忽略我在这里做的兼容性错误？我将来会被这个咬伤吗？我不能升级P，我应该将D降级到8.4.20只是为了安全吗？
答案 0 :(得分：2)
在不同的主要版本中使用pg_dump / pg_restore是个坏主意
通常建议您使用pg_dump作为要恢复的版本。
从旧版本到新版本时，您应该使用较新的pg_dump。
真的很讨厌。
或者可以安全地忽略我在这里做的兼容性错误吗？
这取决于它们是什么。你可以忽略那个，是的。
将来我会被这个咬伤吗？
这取决于你做了什么。显然你不能忽略所有错误 - 例如，如果CREATE TABLE失败你就会遇到麻烦。所以这取决于所使用的功能等。
我不能升级P，我应该将D降级到8.4.20只是为了安全吗？
是。使用您在生产中运行的相同版本进行开发。
你需要迟早升级P.开始计划。它不受支持，不会进一步修复错误，不会打包新的操作系统版本，并且“升级到受支持的版本并查看它是否仍然在那里”，将遇到错误/问题报告。
答案 1 :(得分：1)
对于遇到此问题的人们：最好使用相同版本进行还原。 但是，这通常不切实际
示例：我的本地开发机器主要是Postgres 12.1（端口5433），用于开发下一个版本。我还安装了Postgres 11（端口5432），因为我们的生产和CI仍在Postgres 11上。
所以我做了以下事情：
在PG 12.1中创建测试数据库
将适当的迁移脚本手动应用于CI中使用的示例数据
使用PG 12 pg_dump导出以创建转储文件
"c:\Program Files\PostgreSQL\12\bin\pg_dump" -U postgres -p 5433 -d ut_20200621 --no-owner --no-acl "f:\dumps\ut_20200621_pg12.backup"
"c:\Program Files\PostgreSQL\12\bin\pg_restore" -U postgres -p 5432 -d ut_20200621 --no-owner --no-acl "f:\dumps\ut_20200621_pg12.backup"
"c:\Program Files\PostgreSQL\11\bin\pg_restore" -U postgres -p 5432 -d ut_20200621 --no-owner --no-acl "f:\dumps\ut_20200621_pg12.backup"
然后，我的CI服务器可以使用我手动创建的升级数据库。
对于发行版，数据迁移是手动运行的：首先在登台中，然后在生产中。
答案 2 :(得分：0)
我的经验将转储从9.6恢复到9.5.9 我使用第三台服务器5.9.13 复制文件（最初创建备份）
将文件替换为9.5.13的服务器上
/usr/share/postgresql-common/pg_wrapper
在服务器9.5.13上
pg_restore -U $POSTGRES_USER -h localhost -d $POSTGRES_DB </tmp/dump.sql
创建转储
pg_dump -U $POSTGRES_USER -h localhost -d $POSTGRES_DB -O -x > /tmp/dump_9_5_13.sql
在服务器9.5.9上
psql -U $POSTGRES_USER -h localhost -d $POSTGRES_DB </tmp/dump_9_5_13.sql