pg_restore: [archiveur] version non prise en charge (1.14) dans l'en-tête du fichier

Question

J'ai un serveur en direct et une boîte de développement, appelez-les respectivement live et dev, tous deux exécutant postgresql. Je peux voir les deux et les gérer avec pgadmin4 sans problème, et les deux sont entièrement fonctionnels l'un derrière un site Web en direct et l'autre lorsque je fonctionne par site Web en mode débogage sur la boîte my dev. Configuration assez ordinaire.

Pendant des années, j'ai exécuté le même script bash que j'ai écrit qui vide la base de données en direct, puis la restaure sur la boîte de développement, j'ai donc le dernier instantané en direct avec lequel travailler.

Aujourd'hui, cela me manque avec le message intitulé:

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

J'ai essayé de diagnostiquer cela, et j'ai longuement cherché en ligne, mais je suis découragé et j'ai échoué, alors je suis le bonnet en main pour l'expertise.

Pour vous aider, je partagerai les informations suivantes:

$ 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

Étant donné pg_dump et pg_restore sont des versions identiques et:

$ 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

Je peux voir que ce ne sont pas seulement des versions identiques, mais qu'elles sont exécutées par le même script wrapper (qui se trouve être un script Perl - maintenant c'est un langage que vous ne voyez plus beaucoup et que j'avais l'habitude de coder intensivement)

Je suis donc totalement perplexe. Pensant qu'il peut y avoir un problème de version avec la machine en direct:

$ 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)

Je peux voir que la boîte en direct a une version légèrement plus ancienne de pg_dump (ce qui n'aurait d'importance que si pg_dump sur ma boîte de développement a en quelque sorte utilisé un RPC sur la boîte en direct pour exécuter son pg_dump).

Maintenant, il y a peut-être un petit indice dans le fait que ma boîte de développement a vu quelques mises à niveau postgresql passer et ainsi par exemple:

$ 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

Les clusters 11 et 12 restent inutilisés, comme en témoignent les fichiers journaux vides. J'utilise 10. Mais je remarque que:

$ 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)

qui est légèrement louche mais encore une fois pas une cause ou apparentée:

J'utilise pg_dump pas psql
J'utilise uniquement les outils pg des boîtes de développement et non les boîtes en direct (ils ne devraient pas être pertinents, l'ensemble du transfert de données théoriquement sur le port 5432 sur la boîte en direct qui fournit un vidage de la base de données à pg_dump sur ma boîte de développement.

Voici les clusters sur la love box et c'est sur le port 5432 que sur live.lan je lance 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

Je suis profondément perplexe et paralysé à l'heure actuelle par cela. J'apprécierais profondément les indices en mouvement Si je suis obligé de pêcher dans le noir, je vais probablement désinstaller à nouveau les postgres 11 et 12 et voir si cela aide, sinon je devrai retracer /usr/share/postgresql-common/pg_wrapper pour voir comment et où les deux chemins de pg_dump et pg_restore divergent vers des chemins de version incompatibles.

Mise à jour:

Un autre indice que j'ai découvert, qui me permet une solution de contournement mais approfondit simplement le mystère est le suivant:

$ 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 test.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)

Cela laisse perplexe au-delà de toute croyance. Les seules explications possibles:

malgré les rapports de numéros de version identiques, les deux pg_dumps sont différents. J'exclurais cela au-delà de toute croyance.
pg_dump exécute pg_wrapper qui exécute/usr/lib/postgresql/10/bin/pg_dump avec des arguments mystérieux qui le cassent!

La seconde est plausible et nécessitera que j'instrument pg_wrapper pour diagnostiquer.

Mise à jour 2:

Et une instrumentation de pg_wrapper plus tard. Il en résulte que pg_dump exécute pg_wrapper qui exécute /usr/lib/postgresql/12/bin/pg_dump pourtant il fonctionne /usr/lib/postgresql/10/bin/pg_restore ... Allez comprendre! Commencer à penser que c'est un bug d'interopérabilité de la version postgresql!

Mise à jour 3:

En approfondissant pg_wrapper, a cloué la cause, et oui, je dirais que c'est un bug pg_wrapper d'un genre bien qu'il puisse être discutable, à peine si IMHO. Voici ce qu'il fait:

Si --Host est fourni puis il utilise la dernière version de postgresql installée (12 dans mon cas et c'est pour pg_dump, donc pg_dump 12 crée le dump)

Si --Host n'est pas fourni alors il consulte la configuration utilisateur (10 dans mon cas, et c'est pour pg_restore, donc pg_restore 10 est exécuté et il ne peut pas lire un fichier créé par pg_dump 12).

Alors pourquoi est-ce un bug? Parce que j'ai une configuration d'utilisation, et je voudrais qu'elle soit respectée, que je parle ou non à un hôte distant. Plus précisément, si je spécifie un hôte, je ne m'attends certainement pas à utiliser la dernière version locale en ignorant la configuration locale. Je m'attendrais à respecter la configuration locale (comme c'est le cas quand aucun hôte distant n'est spécifié) ou à essayer de faire correspondre la version des hôtes rmeote. S'appuyer arbitrairement sur la dernière version installée est à mon humble avis profondément discutable.

MAIS il s'avère qu'il existe une solution de contournement qui fonctionne. Essentiellement au lieu de:

Sudo -u postgres pg_restore -l test.backup

cela marche:

Sudo -u postgres pg_restore --Host=localhost -l test.backup

Ironiquement, en spécifiant l'hôte, nous le forçons à ignorer les configurations locales et à utiliser la dernière version de pg_restore qui semble fonctionner correctement dans un cluster PG 10.

Jan · Answer

Voici une autre tournure, mais veuillez noter d'abord qu'il s'agit d'un étui Windows. Si c'est juste Linux pour vous, ne lisez pas plus loin. Tous les conseils donnés ici ne m'ont pas aidé, finalement la cause IMC était plus simple et avait à voir avec l'utilisation de pgAdmin. En raison du bourrage répétitif pour les versions plus récentes, mon habitude est d'installer pgAdmin séparément (sans utiliser stackbuilder). (AU MOINS) dans ce cas, pgAdmin a son propre cache de programmes utilitaires et les utilisera à moins que vous ne le disiez différemment. Mes instances pg sont toujours la version 11 (.6), mais le dernier pgAdmin aura probablement des utilitaires V12. Ce qui peut très bien provoquer une divergence de version. Cela s'est glissé sur moi après avoir effectué un certain nombre de transferts réussis de ma machine principale vers un ordinateur portable. Donc, dans pgAdmin do (menu) Fichier-> préférences-> Chemins et définissez les chemins binaires correspondant à votre installation postgres, IMC C:\Program Files\PostgreSQL\11\bin. Cela a fait l'affaire.