我有一个live服务器和一个development box，分别称它们为live和dev，它们都运行postgresql。我可以用pgadmin 4查看和管理它们，没有任何问题，而且它们都是功能齐全的，一个是live网站，另一个是在我的dev box上以调试模式运行我的网站。非常普通的设置。
多年来，我一直在运行我编写的同一个bash脚本，该脚本转储实时数据库，然后在开发环境中恢复它，这样我就有了最新的实时快照。
今天，这条信息让我失望了：

pg_restore: [archiver] unsupported version (1.14) in file header

我曾试图诊断这一点，并在网上广泛搜索，但被困扰，并已失败，所以在这里我毕恭毕敬的专业知识。
为了提供帮助，我将分享以下内容：

$ pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ pg_restore --version
pg_restore (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test.backup
$ ls -l test.backup 
-rw-r--r-- 1 bernd bernd 2398358 Dec 23 23:40 test.backup
$ file test.backup 
test.backup: PostgreSQL custom database dump - v1.14-0
$ pg_restore --dbname=mydb test.backup 
pg_restore: [archiver] unsupported version (1.14) in file header

假设pg_dump和pg_restore是相同的版本，并且：

$ which pg_dump
/usr/bin/pg_dump
$ which pg_restore
/usr/bin/pg_restore
$ ls -l /usr/bin/pg_dump /usr/bin/pg_restore
lrwxrwxrwx 1 root root 37 Nov 14 23:23 /usr/bin/pg_dump -> ../share/postgresql-common/pg_wrapper
lrwxrwxrwx 1 root root 37 Nov 14 23:23 /usr/bin/pg_restore -> ../share/postgresql-common/pg_wrapper

我可以看到它们不仅是相同的版本，而且是由相同的 Package 器脚本运行的（碰巧是Perl脚本--现在这种语言已经不多见了，我过去经常用它来编写代码）
所以我很困惑，我想可能是这台机器的版本有问题：

$ ssh live.lan
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)
$ which pg_dump
/usr/bin/pg_dump
$ which pg_restore
/usr/bin/pg_restore
$ pg_dump --version
pg_dump (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)
$ pg_restore --version
pg_restore (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)

我可以看到live box确实有稍微旧一点的pg_dump版本（这只会在我的dev box上的pg_dump以某种方式使用了一个RPC到live box来运行它的pg_dump时才有关系）。
现在，我的开发工具箱已经看到了一些postgresql升级，这可能是一个小线索，例如：

$ pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
10  main    5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11  main    5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12  main    5434 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log

11和12个集群仍然未使用，这可以从空的日志文件中看出。我使用的是10个集群。但我注意到：

$ psql --version
psql (PostgreSQL) 12.1 (Ubuntu 12.1-1.pgdg18.04+1)
$ ssh live.lan
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)
$ psql --version
psql (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)

这有点可疑，但也不是明显的原因或相关：
1.我使用的是pg_dump而不是psql
1.我只使用了开发盒pg工具，而不是现场盒（他们应该是无关紧要的，整个数据传输理论上通过端口5432的现场盒，其中提供了一个数据库转储到pg_dump我的开发盒。
这是love box上的集群，它通过live.lan上的端口5432，我正在运行pg_dump！

$ pg_lsclusters 
Ver Cluster Port Status Owner    Data directory           Log file
10  main    5432 online postgres /data/postgresql/10/main /var/log/postgresql/postgresql-10-main.log

目前我对此深感困惑和困扰。非常感谢向前移动的线索。如果我不得不在黑暗中四处寻找，我可能会再次卸载postgres 11和12，看看是否有帮助，否则我将不得不跟踪/usr/share/postgresql-common/pg_wrapper，看看pg_dump和pg_restore这两条路径是如何以及在哪里分叉成不兼容的版本路径的。

更新日期：

我发现的另一个线索，这允许我一个变通办法，但只是加深了神秘如下：

$ sudo -u postgres pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test.backup
$ sudo -u postgres /usr/lib/postgresql/10/bin/pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test2.backup
$ sudo -u postgres pg_restore -l test.backup
pg_restore: [archiver] unsupported version (1.14) in file header
$ sudo -u postgres pg_restore -l test2.backup
... produces listing of contents ...
$ sudo -u postgres pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ sudo -u postgres /usr/lib/postgresql/10/bin/pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)

这真是令人难以置信的困惑。唯一可能的解释是：
1.尽管报告了相同的版本号，但两个pg_dump是不同的。我会排除这一点，因为难以置信。

1. pg_dump运行pg_wrapper，它运行/usr/lib/postgresql/10/bin/pg_dump，并带有一些神秘的参数来破坏它！
   第二个是合理的，需要我对pg_wrapper进行检测来进行诊断。

更新2：

然后对pg_wrapper进行了一次检测。结果是pg_dump运行pg_wrapper，而pg_wrapper运行/usr/lib/postgresql/12/bin/pg_dump，而它运行/usr/lib/postgresql/10/bin/pg_restore...想想看！开始认为这是postgresql版本的互操作性错误！

更新3：

深入研究pg_wrapper，找到了原因，是的，我认为这是一个pg_wrapper bug，尽管它可能有争议，但恕我直言。
如果提供了--host，则它使用安装的postgresql的最新版本（在我的例子中是12，这是用于pg_dump的，所以pg_dump 12创建转储）
如果没有提供--host，它会参考用户配置（在我的例子中是10，这是针对pg_restore的，所以pg_restore 10运行，它不能读取pg_dump 12创建的文件）。
那为什么这是个bug呢？因为我有一个使用配置，而且我希望无论我是否在与远程主机对话都能遵守它。更重要的是，如果我指定了一个主机，我当然不希望使用最新的本地版本而忽略本地配置。（就像没有指定远程主机时的情况一样）或尝试匹配远程主机版本。任意依赖最新安装的版本是非常值得怀疑的。
但事实证明，有一个变通办法是有效的。本质上不是：

sudo -u postgres pg_restore -l test.backup

这是可行的：

sudo -u postgres pg_restore --host=localhost -l test.backup

通过讽刺地指定主机，我们强制它忽略本地配置，并使用最新版本的pg_restore，它似乎可以很好地恢复到PG 10集群。