psql comando non valido \ N durante il ripristino di sql


137

Sto cercando di ripristinare il mio file di dump, ma ha causato un errore:

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

C'è una soluzione? Ho cercato, ma non ho avuto una risposta chiara.

Risposte:


198

Postgres usa "\ N" come simbolo sostitutivo per il valore NULL. Ma tutti i comandi psql iniziano con la barra rovesciata "\". Quindi puoi ricevere questi messaggi, quando probabilmente l'istruzione copy fallisce, ma il caricamento del dump continua. Questo messaggio è solo un falso allarme. Devi cercare una riga prima per il motivo per cui l'istruzione COPY non riesce.

È possibile cambiare psql in modalità "stop on first error" e trovare l'errore:

psql -v ON_ERROR_STOP=1

7
Sì, un errore molto, molto semplice da fare in quanto il numero di questi errori di comando non validi può essere estremamente grande, oscurando completamente il primo errore che ha colpito all'inizio.
crowmagnumb,

5
È abbastanza male da PostgreSQL dare un avvertimento così fuorviante, la tua risposta mi ha fatto risparmiare un sacco di tempo!
Tregoreg,

50
@Tregoreg - sì, non è amichevole - puoi eseguire psql in modalità "stop on first error". Semplifica la diagnostica "psql -v ON_ERROR_STOP = 1"
Pavel Stehule,

2
Può accadere quando, ad esempio, create table...non si avvia all'inizio, ma il caricamento continua.
JaakL,

1
Sono venuto qui per lo stesso errore. Quello che ho capito era di fare: (pg_restore ... | psql ...) 2>&1 | less
THK,

33

Vado lo stesso messaggio di errore quando provo a ripristinare da un dump binario. Ho semplicemente usato pg_restoreper ripristinare il mio dump ed evitare completamente gli \Nerrori, ad es

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

Spiegazione degli interruttori:

-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


anche un utilizzo della CPU molto più basso, no?
catbadger

15

So che questo è un vecchio post, ma ho trovato un'altra soluzione: Postgis non è stato installato sulla mia nuova versione, il che mi ha causato lo stesso errore su pg_dump


1
Che salvavita!
matmat

8

Ho riscontrato questo errore anche in passato. Pavel ha ragione, di solito è un segno che qualcosa nello script creato da pg_restore sta fallendo. A causa di tutti gli errori "/ N", non si vede il vero problema nella parte superiore dell'output. Suggerisco:

  1. inserendo un singolo tavolino (ad es. pg_restore --table=orders full_database.dump > orders.dump )
  2. se non ne hai uno piccolo, quindi elimina un sacco di record dallo script di ripristino - mi sono appena assicurato che ./ fosse l'ultima riga da caricare (ad esempio, apri orders.dump ed elimina un gruppo di record)
  3. guarda l'output standard e, una volta riscontrato il problema, puoi sempre eliminare la tabella e ricaricare

Nel mio caso, non avevo ancora installato l'estensione "hstore", quindi lo script non funzionava in cima. Ho installato hstore sul database di destinazione ed ero di nuovo in affari.


"Non avevo ancora installato l'estensione" hstore ", TNX.
Arash Fatahzade,

7

Puoi generare il tuo dump usando le istruzioni INSERTS, con il parametro --inserts.


2
Questo funziona per me! pg_dump --inserisce $ DATABASE> $ FILENAME
Abel

4

Installa postgresql- (la tua versione) -postgis-script


4

La stessa cosa mi è successa oggi. Ho risolto il problema scaricando con il comando --inserts.

Quello che faccio è:

1) pg_dump con inserti:

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

2) psql (ripristina il file scaricato)

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

Nota-1) Assicurarsi che l'aggiunta del file di output aumenti la velocità di importazione.

Nota-2) Non dimenticare di creare una tabella con lo stesso identico nome e colonne prima di importare con psql.


2

Nella mia recente esperienza, è possibile ottenere questo errore quando il vero problema non ha nulla a che fare con i caratteri di escape o le nuove righe. Nel mio caso, avevo creato un dump dal database A con
pg_dump -a -t table_name > dump.sql
e stavo provando a ripristinarlo nel database B con
psql < dump.sql(ovviamente dopo aver aggiornato gli appropriati variatori)
Quello che ho finalmente capito era che il dump, sebbene fosse data-only(l' -aopzione , in modo che la struttura della tabella non facesse esplicitamente parte del dump), era specifica dello schema. Ciò significava che senza modificare manualmente il dump, non avrei potuto usare un dump generato da schema1.table_namepopolare schema2.table_name. Modificare manualmente il dump è stato facile, lo schema è specificato nelle prime 15 righe circa.


1

La maggior parte delle volte, la soluzione è installare il postgres-contribpacchetto.


0

Per me usando postgreSQL 10 su SUSE 12, ho risolto l' invalid command \Nerrore aumentando lo spazio su disco. La mancanza di spazio su disco stava causando l'errore per me. È possibile sapere se lo spazio su disco è insufficiente se si guarda al file system in cui verranno inviati i dati df -hnell'output. Se il file system / mount viene utilizzato al 100%, dopo aver fatto qualcosa del genere psql -f db.out postgres(vedi https://www.postgresql.org/docs/current/static/app-pg-dumpall.html ) probabilmente dovrai aumentare lo spazio disponibile su disco .


0

Ho avuto lo stesso problema, ho creato un nuovo database e ho invalid command \Nripristinato con psql. L'ho risolto impostando lo stesso tablespace con il vecchio database.

Ad esempio, il vecchio backup del database aveva il tablespace "pg_default", ho definito lo stesso tablespace per il nuovo database e l'errore sopra è andato!


0

Ho seguito tutti questi esempi e tutti hanno fallito con l'errore di cui stiamo parlando:

Copia una tabella da un database all'altro in Postgres

Ciò che ha funzionato è stata la sintassi con -C , vedi qui:

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

Inoltre, se ci sono schemi differenti tra i due, trovo che alterare lo schema di un dB in modo che corrisponda agli altri è necessario per il funzionamento delle copie della tabella, ad esempio:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.