pg_restore: [archiver] versão não suportada (1.14) no cabeçalho do arquivo

Eu tenho um servidor ativo e uma caixa de desenvolvimento, chame-os de vivo e dev, respectivamente, ambos executando o postgresql. Eu posso ver os dois e gerenciar ambos com o pgadmin4 sem problemas, e ambos são totalmente funcionais: um atrás de um site ativo e o outro quando eu corro por site no modo de depuração na minha caixa de desenvolvimento. Configuração bastante comum.

Por anos, eu tenho executado o mesmo script bash que escrevi que despeja o banco de dados ao vivo e depois o restaura na caixa de desenvolvimento, para que eu tenha o último instantâneo ao vivo para trabalhar.

Hoje isso me falha com a mensagem intitulada:

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

Eu tentei diagnosticar isso e procurei extensivamente on-line, mas estou atormentado e falhei, então aqui estou eu na mão para obter conhecimento.

Para ajudar, compartilharei o seguinte:

$ 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 que pg_dump e pg_restore são versões idênticas e:

$ 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

Eu posso ver que elas não são apenas versões idênticas, mas são executadas pelo mesmo script wrapper (que por acaso é um script perl - agora é uma linguagem que você não vê muito e eu costumava codificar extensivamente)

Então, eu fico totalmente perplexo. Pensando que pode haver um problema de versão na máquina ativa:

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

Eu posso ver que a caixa ao vivo tem uma versão um pouco mais antiga do pg_dump (o que seria importante se o pg_dump na minha caixa de desenvolvimento de alguma forma usasse um RPC na caixa ao vivo para executar seu pg_dump).

Agora, talvez haja uma pequena pista no fato de que minha caixa de desenvolvimento já viu algumas atualizações do postgresql, e por exemplo:

$ 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

Os 11 e 12 clusters permanecem sem uso, conforme evidenciado por arquivos de log vazios. Estou usando 10. Mas noto 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)

que é levemente suspeito, mas novamente não é obviamente uma causa ou relação:

1. Estou usando pg_dump não psql
2. Estou usando apenas as ferramentas dev box pg e não as caixas ativas (elas devem ser irrelevantes, todos os dados são transferidos teoricamente pela porta 5432 na caixa ativa, que fornece um dump de dados para pg_dump na minha caixa dev.

Aqui estão os clusters na caixa do amor e está na porta 5432 que no live.lan estou executando o 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

No momento, estou profundamente perplexo e confuso. Apreciaria profundamente pistas para a frente. Se eu sou obrigado a pescar no escuro, provavelmente desinstalarei o postgres 11 e 12 novamente e verei se isso ajuda. Caso contrário, acabarei tendo que rastrear /usr/share/postgresql-common/pg_wrapperpara ver como e onde os dois caminhos de pg_dump e pg_restore divergem nos caminhos incompatíveis da versão .

Atualizar:

Outra pista que descobri, que me permite uma solução alternativa, mas simplesmente aprofunda o mistério é a seguinte:

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

Isso é desconcertante além da crença. As únicas explicações possíveis:

1. apesar de relatar números de versão idênticos, os dois pg_dumps são diferentes. Eu descartaria isso como algo além da crença.
2. O pg_dump executa o pg_wrapper que executa / usr / lib / postgresql / 10 / bin / pg_dump com alguns argumentos misteriosos que o quebram!

O segundo é plausível e exigirá que eu instrua o pg_wrapper para diagnosticar.

Atualização 2:

E uma instrumentação de pg_wrapper mais tarde. Ele conclui que o pg_dump executa o pg_wrapper, que /usr/lib/postgresql/12/bin/pg_dumpainda funciona /usr/lib/postgresql/10/bin/pg_restore... Vá em frente! Começando a pensar que isso é um bug de interoperabilidade da versão postgresql!

Atualização 3:

Olhando mais fundo pg_wrapper, acertando a causa, e sim, eu diria que é um bug do tipo pg_wrapper, embora possa ser discutível, apesar de IMHO. Aqui está o que ele faz:

E se --host for fornecido, ele usa a versão mais recente do postgresql instalada (12 no meu caso e isso é para pg_dump, portanto, pg_dump 12 cria o dump)

Se --hostnão for fornecido, ele consultará a configuração do usuário (10 no meu caso, e isso é para pg_restore, portanto, o pg_restore 10 é executado e não pode ler um arquivo criado por pg_dump 12).

Então, por que isso é um bug? Porque eu tenho uma configuração de uso e gostaria que fosse respeitado se estou falando ou não com um host remoto. Mais especificamente, se eu especificar um host, certamente não espero usar a versão local mais recente, ignorando a configuração local. Eu esperaria respeitar a configuração local (como é o caso quando nenhum host remoto for especificado) ou tentar corresponder à versão dos hosts rmeote. Inclinar-se arbitrariamente na versão mais recente instalada é IMHO profundamente questionável.

Mas acontece que existe uma solução alternativa que funciona. Essencialmente, em vez de:

sudo -u postgres pg_restore -l test.backup

isso funciona:

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

Ao especificar o host ironicamente, forçamos que ele ignore as configurações locais e use a versão mais recente do pg_restore, que parece funcionar perfeitamente na restauração de um cluster PG 10.

Aqui está outra reviravolta, mas observe primeiro que este é um caso do Windows. Se for apenas linux para você, não leia mais. Todos os conselhos dados aqui não me ajudaram; eventualmente, a causa IMC era mais simples e tinha a ver com o uso do pgAdmin. Devido ao problema repetitivo das versões mais recentes, meu hábito é instalar o pgAdmin separadamente (não usando o stackbuilder). (PELO MENOS), nesse caso, o pgAdmin possui seu próprio cache de programas utilitários e os utilizará, a menos que você o diga de maneira diferente. Minhas instâncias pg ainda são a versão 11 (.6), mas as últimas pgAdmin provavelmente terão utilitários V12. O que pode muito bem causar uma discrepância de versão. Isso me ocorreu depois de fazer várias transferências bem-sucedidas da minha máquina principal para um laptop. Portanto, no pgAdmin do (menu) Arquivo-> preferências-> Caminhos e defina Caminhos Binários correspondentes à sua instalação do postgres, C IMC: \ Arquivos de programas \ PostgreSQL \ 11 \ bin. Isso fez o trabalho.

verifique e verifique se o seu pgadmin está atualizado, eu tive esse problema e o resolvi atualizando-o

Esse erro é causado por uma incompatibilidade de versão entre a versão do pg_dump usada para criar o arquivo de backup e a versão do pg_restore usada para tentar a restauração.

A atualização do meu PostgreSQL resolveu o problema