pg_restore: [archiver] versión no compatible (1.14) en el encabezado del archivo

Tengo un servidor en vivo y un cuadro de desarrollo, los llamo live y dev respectivamente, ambos ejecutan postgresql. Puedo ver ambos y administrarlos con pgadmin4 sin problemas, y ambos son completamente funcionales, uno detrás de un sitio web en vivo y el otro cuando ejecuto un sitio web en modo de depuración en mi cuadro de desarrollo. Configuración bastante ordinaria.

Durante años, he estado ejecutando el mismo script de bash que escribí que volca la base de datos en vivo y luego la restaura en el cuadro de desarrollo, así que tengo la última instantánea en vivo para trabajar.

Hoy esto me falla con el mensaje titulado:

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

Traté de diagnosticar esto y busqué extensamente en línea, pero estoy atormentado y he fallado, así que aquí tengo un tope para la experiencia.

Para ayudar compartiré lo siguiente:

$ 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

Dado pg_dump y pg_restore son versiones idénticas y:

$ 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

Puedo ver que no son solo versiones idénticas, sino que se ejecutan con el mismo script de contenedor (que resulta ser un script perl, ahora ese es un lenguaje que ya no se ve mucho y solía codificar ampliamente)

Así que me quedo totalmente perplejo. Pensando que puede haber un problema de versión con la máquina en vivo:

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

Puedo ver que el cuadro en vivo tiene una versión un poco más antigua de pg_dump (lo que solo importaría si pg_dump en mi cuadro de desarrollo de alguna manera usara un RPC en el cuadro en vivo para ejecutar su pg_dump).

Ahora, tal vez haya una pequeña pista en el hecho de que mi caja de desarrollo ha visto algunas actualizaciones postgresql, por ejemplo:

$ 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

Los grupos 11 y 12 permanecen sin usar, como lo demuestran los archivos de registro vacíos. Estoy usando 10. Pero me doy cuenta de 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)

lo cual es ligeramente sospechoso, pero nuevamente no es obviamente una causa o relacionada:

1. Estoy usando pg_dump no psql
2. Estoy usando solo las herramientas pg de los cuadros de desarrollo, no las cajas vivas (deberían ser irrelevantes, la transferencia de datos completa teóricamente a través del puerto 5432 en el cuadro en vivo que entrega un volcado de databse a pg_dump en mi cuadro de desarrollo.

Aquí están los grupos en la caja de amor y está sobre el puerto 5432 que en live.lan estoy ejecutando 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

Estoy profundamente perplejo y aturdido en este momento por esto. Apreciaría profundamente las pistas que avanzan. Si me veo obligado a pescar en la oscuridad, probablemente desinstalaré postgres 11 y 12 nuevamente y veré si eso ayuda, de lo contrario terminaré teniendo que rastrear /usr/share/postgresql-common/pg_wrapperpara ver cómo y dónde las dos rutas de pg_dump y pg_restore divergen por rutas de versiones incompatibles .

Actualizar:

Otra pista que he descubierto, que me permite una solución alternativa, pero que simplemente profundiza el misterio, es la siguiente:

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

Eso es desconcertante más allá de la creencia. Las únicas explicaciones posibles:

1. a pesar de informar números de versión idénticos, los dos pg_dumps son diferentes. Yo descartaría esto como algo increíble.
2. pg_dump ejecuta pg_wrapper que ejecuta / usr / lib / postgresql / 10 / bin / pg_dump con algunos argumentos misteriosos que lo rompen.

El segundo es plausible y requerirá que instrumente pg_wrapper para diagnosticar.

Actualización 2:

Y una instrumentación de pg_wrapper más tarde. Eventualmente, pg_dump ejecuta pg_wrapper que se ejecuta /usr/lib/postgresql/12/bin/pg_dumppero se ejecuta /usr/lib/postgresql/10/bin/pg_restore... ¡Vaya! ¡Empezando a pensar que esto es un error de interoperabilidad de la versión postgresql!

Actualización 3:

Mirando más profundamente pg_wrapper, clavó la causa, y sí, diría que es un error de tipo pg_wrapper, aunque puede ser discutible, aunque en mi humilde opinión. Esto es lo que hace:

Si --hostse proporciona, entonces utiliza la versión más reciente de postgresql instalada (12 en mi caso y esto es para pg_dump, por lo que pg_dump 12 crea el volcado)

Si --hostno se proporciona, consulta la configuración del usuario (10 en mi caso, y esto es para pg_restore, por lo que se ejecuta pg_restore 10 y no puede leer un archivo creado por pg_dump 12).

Entonces, ¿por qué es esto un error? Porque tengo una configuración de uso y me gustaría que se respete si estoy hablando con un host remoto o no. Más aún, si especifico un host, ciertamente no espero usar la última versión local ignorando la configuración local. Esperaría respetar la configuración local (como es el caso cuando no se especifica un host remoto) o intentar hacer coincidir la versión de rmeote hosts. Apoyarse arbitrariamente en la última versión instalada es, en mi humilde opinión, profundamente cuestionable.

PERO resulta que hay una solución alternativa que funciona. Esencialmente en lugar de:

sudo -u postgres pg_restore -l test.backup

esto funciona:

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

Al especificar irónicamente el host, lo forzamos a ignorar las configuraciones locales y usar la versión más reciente de pg_restore, que parece funcionar bien restaurando a un clúster PG 10.

Aquí hay otro giro, pero tenga en cuenta primero que este es un caso de Windows. Si solo es Linux para ti, no sigas leyendo. Todos los consejos dados aquí no me ayudaron, eventualmente la causa IMC fue más simple y tuvo que ver con el uso de pgAdmin. Debido a la molestia repetitiva para las versiones más nuevas, mi costumbre es instalar pgAdmin por separado (no usando stackbuilder). (AL MENOS) en ese caso, pgAdmin tiene su propio caché de programas de utilidad y los usará a menos que lo indique de manera diferente. Mis instancias de pg siguen siendo la versión 11 (.6), pero la última pgAdmin probablemente tendrá utilidades V12. Lo cual puede causar una discrepancia de versión. Esto se apoderó de mí después de hacer varias transferencias exitosas desde mi máquina principal a una computadora portátil. Entonces, en pgAdmin do (menú) Archivo-> preferencias-> Rutas y establezca Rutas binarias correspondientes a su instalación de postgres, IMC C: \ Archivos de programa \ PostgreSQL \ 11 \ bin. Eso hizo el trabajo.

compruebe y vea si su pgadmin está actualizado, tuve este problema y lo resolví actualizándolo

Este error es causado por una discrepancia de versión entre la versión de pg_dump utilizada para crear el archivo de copia de seguridad y la versión de pg_restore utilizada para intentar la restauración.

Actualizar mi PostgreSQL resolvió el problema