comando \ n inválido do psql enquanto restaura o sql

Estou tentando restaurar meu arquivo de despejo, mas causou um erro:

psql:psit.sql:27485: invalid command \N

Há uma solução? Eu procurei, mas não obtive uma resposta clara.

O Postgres usa "\ N" como símbolo substituto do valor NULL. Mas todos os comandos psql começam com o símbolo "\" barra invertida. Portanto, você pode receber essas mensagens, quando provavelmente a instrução de cópia falhar, mas o carregamento do dump continua. Esta mensagem é apenas um alarme falso. Você deve procurar uma linha antes pelo motivo pelo qual a instrução COPY falha.

É possível alternar o psql para o modo "parar no primeiro erro" e encontrar o erro:

psql -v ON_ERROR_STOP=1

Eu recebo a mesma mensagem de erro ao tentar restaurar de um despejo binário. Simplesmente usei pg_restorepara restaurar meu despejo e evitar completamente os \Nerros, por exemplo

pg_restore -c -F t -f your.backup.tar

Explicação dos comutadores:

-f, --file=FILENAME output file name -F, --format=c|d|t backup file format (should be automatic) -c, --clean clean (drop) database objects before recreating

Eu sei que este é um post antigo, mas me deparei com outra solução: o postgis não estava instalado na minha nova versão, o que me causou o mesmo erro no pg_dump

Também encontrei esse erro no passado. Pavel está correto, geralmente é um sinal de que algo no script criado por pg_restore está falhando. Devido a todos os erros "/ N", você não está vendo o problema real na parte superior da saída. Eu sugiro:

1. inserindo uma única tabela pequena (por exemplo, pg_restore --table=orders full_database.dump > orders.dump)
2. se você não tiver um pequeno, exclua um monte de registros do script de restauração - verifiquei se o ./ era a última linha a ser carregada (por exemplo, abra orders.dumpe exclua um monte de registros)
3. observe a saída padrão e, assim que encontrar o problema, você sempre pode soltar a mesa e recarregar

No meu caso, eu ainda não tinha a extensão "hstore" instalada, portanto, o script estava falhando no topo. Instalei o hstore no banco de dados de destino e estava de volta aos negócios.

Você pode gerar seu dump usando instruções INSERTS, com o parâmetro --inserts.

Instale postgresql- (sua versão) -postgis-scripts

A mesma coisa aconteceu comigo hoje. Eu lidei com o problema fazendo o dumping com o comando --inserts.

O que eu faço é:

1) pg_dump com inserções:

pg_dump dbname --username=usernamehere --password --no-owner --no-privileges --data-only --inserts -t 'schema."Table"' > filename.sql

2) psql (restaure seu arquivo despejado)

psql "dbname=dbnamehere options=--search_path=schemaname" --host hostnamehere --username=usernamehere -f filename.sql >& outputfile.txt

Nota-1) Certifique-se de que adicionar arquivo de saída aumente a velocidade de importação.

Nota-2) Não se esqueça de criar tabela com exatamente o mesmo nome e colunas antes de importar com o psql.

Na minha experiência recente, é possível obter esse erro quando o problema real não tem nada a ver com caracteres de escape ou novas linhas. No meu caso, eu criei um dump do banco de dados A com
pg_dump -a -t table_name > dump.sql
e estava tentando restaurá-lo no banco de dados B
psql < dump.sql(depois de atualizar os envios adequados, é claro).
O que eu finalmente descobri foi que o dump, embora fosse data-only(a -aopção , para que a estrutura da tabela não faça parte explicitamente do despejo), era específica do esquema. Isso significava que, sem modificar manualmente o dump, eu não poderia usar um dump gerado a partir schema1.table_namepara preencher schema2.table_name. A modificação manual do dump foi fácil, o esquema é especificado nas primeiras 15 linhas, aproximadamente.

Na maioria das vezes, a solução é instalar o postgres-contribpacote.

Para mim, usando o postgreSQL 10 no SUSE 12, resolvi o invalid command \Nerro aumentando o espaço em disco. A falta de espaço em disco estava causando o erro para mim. Você pode saber se está sem espaço em disco se olhar para o sistema de arquivos para onde seus dados estão indo na df -hsaída. Se o sistema de arquivos / montagem estiver 100% usado, depois de fazer algo como psql -f db.out postgres(consulte https://www.postgresql.org/docs/current/static/app-pg-dumpall.html ), você provavelmente precisará aumentar o espaço em disco disponível .

Eu tive o mesmo problema, criei um novo banco de dados e invalid command \Nrestaurei com o psql. Eu o resolvi definindo o mesmo espaço de tabela no banco de dados antigo.

Por exemplo, o backup antigo do banco de dados tinha o espaço de tabela "pg_default", eu defini o mesmo espaço de tabela para o novo banco de dados e o erro acima foi eliminado!

Eu segui todos esses exemplos e todos falharam com o erro que estamos falando:

Copie uma tabela de um banco de dados para outro no Postgres

O que funcionou foi a sintaxe com -C , veja aqui:

pg_dump -C -t tableName "postgres://$User:$Password@$Host:$Port/$DBName" | psql "postgres://$User:$Password@$Host:$Port/$DBName"

Além disso, se houver esquemas diferentes entre os dois, acho que é necessário alterar o esquema de um dB para corresponder aos outros para que as cópias da tabela funcionem, por exemplo:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;