psql ungültiger Befehl \ N beim Wiederherstellen von SQL


137

Ich versuche, meine Dump-Datei wiederherzustellen, aber es ist ein Fehler aufgetreten:

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

Gibt es eine Lösung? Ich habe gesucht, aber keine klare Antwort erhalten.

Antworten:


198

Postgres verwendet "\ N" als Ersatzsymbol für den NULL-Wert. Alle psql-Befehle beginnen jedoch mit dem Backslash-Symbol "\". Sie können diese Meldungen also erhalten, wenn die Kopieranweisung wahrscheinlich fehlschlägt, das Laden des Speicherauszugs jedoch fortgesetzt wird. Diese Meldung ist nur ein Fehlalarm. Sie müssen vorher eine Zeile nach dem Grund durchsuchen, warum die COPY-Anweisung fehlschlägt.

Ist es möglich, psql in den Modus "Stop on first error" zu schalten und Fehler zu finden:

psql -v ON_ERROR_STOP=1

7
Ja, ein sehr, sehr einfacher Fehler, da die Anzahl dieser ungültigen Befehlsfehler extrem groß sein kann und den ersten Fehlertreffer frühzeitig verdeckt.
Crowmagnumb

5
Es ist ziemlich böse von PostgreSQL, solch eine irreführende Warnung zu geben. Ihre Antwort hat mir viel Zeit gespart!
Tregoreg

50
@Tregoreg - ja, es ist nicht freundlich - Sie können psql im Modus "Stop on first error" ausführen. Es vereinfacht die Diagnose "psql -v ON_ERROR_STOP = 1"
Pavel Stehule

2
Kann passieren, wenn z. B. create table...der Start fehlschlägt, das Laden jedoch fortgesetzt wird.
JaakL

1
Ich bin wegen des gleichen Fehlers hierher gekommen. Was ich herausgefunden habe, war zu tun: (pg_restore ... | psql ...) 2>&1 | less
THK

33

Ich versuche die gleiche Fehlermeldung, wenn ich versuche, von einem binären Speicherauszug wiederherzustellen. Ich habe einfach pg_restoremeinen Dump wiederhergestellt und die \NFehler vollständig vermieden, z

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

Erklärung der Schalter:

-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


auch viel weniger CPU-Auslastung, nicht wahr?
Catbadger

15

Ich weiß, dass dies ein alter Beitrag ist, aber ich bin auf eine andere Lösung gestoßen: postgis wurde auf meiner neuen Version nicht installiert, was mir den gleichen Fehler auf pg_dump verursachte


1
Was für ein Lebensretter!
Matmat

8

Ich bin auch in der Vergangenheit auf diesen Fehler gestoßen. Pavel ist korrekt, es ist normalerweise ein Zeichen dafür, dass etwas in dem von pg_restore erstellten Skript fehlschlägt. Aufgrund all der "/ N" -Fehler sehen Sie das eigentliche Problem nicht ganz oben in der Ausgabe. Ich schlage vor:

  1. Einfügen einer einzelnen kleinen Tabelle (z. B. pg_restore --table=orders full_database.dump > orders.dump)
  2. Wenn Sie keine kleine haben, löschen Sie eine Reihe von Datensätzen aus dem Wiederherstellungsskript. Ich habe nur sichergestellt, dass ./ die letzte zu ladende Zeile ist (z. B. orders.dumpeine Reihe von Datensätzen öffnen und löschen).
  3. Beobachten Sie die Standardausgabe, und sobald Sie das Problem gefunden haben, können Sie die Tabelle jederzeit löschen und neu laden

In meinem Fall war die Erweiterung "hstore" noch nicht installiert, sodass das Skript ganz oben fehlschlug. Ich habe hstore in der Zieldatenbank installiert und war wieder im Geschäft.


"Ich hatte die Erweiterung" hstore "noch nicht installiert", TNX.
Arash Fatahzade

7

Sie können Ihren Speicherauszug mithilfe von INSERTS-Anweisungen mit dem Parameter --inserts generieren.


2
Das funktioniert bei mir! pg_dump - fügt $ DATABASE> $ FILENAME ein
Abel

4

Installieren Sie postgresql- (Ihre Version) -postgis-Skripte


4

Das gleiche ist mir heute passiert. Ich habe das Problem durch Dumping mit dem Befehl --inserts behoben.

Was ich tue ist:

1) pg_dump mit Einfügungen:

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

2) psql (stelle deine gedumpte Datei wieder her)

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

Hinweis 1) Stellen Sie sicher, dass das Hinzufügen einer Ausgabedatei die Importgeschwindigkeit erhöht.

Hinweis-2) Vergessen Sie nicht, vor dem Import mit psql eine Tabelle mit genau demselben Namen und denselben Spalten zu erstellen.


2

Nach meiner jüngsten Erfahrung ist es möglich, diesen Fehler zu erhalten, wenn das eigentliche Problem nichts mit Escapezeichen oder Zeilenumbrüchen zu tun hat. In meinem Fall hatte ich einen Dump aus Datenbank A mit erstellt
pg_dump -a -t table_name > dump.sql
und versuchte, ihn in Datenbank B mit wiederherzustellen
psql < dump.sql(natürlich nach dem Aktualisieren der richtigen env-Variablen).
Schließlich stellte ich fest, dass es sich um den Dump handelte (obwohl dies data-onlyder -aFall war) war schemaspezifisch, damit die Tabellenstruktur nicht explizit Teil des Speicherauszugs ist. Das bedeutete, dass ich ohne manuelles Ändern des Dumps keinen Dump verwenden konnte, der schema1.table_namezum Auffüllen generiert wurde schema2.table_name. Das manuelle Ändern des Speicherauszugs war einfach. Das Schema wird in den ersten 15 Zeilen oder so angegeben.


1

In den meisten Fällen besteht die Lösung darin, das postgres-contribPaket zu installieren .


0

Bei Verwendung von postgreSQL 10 unter SUSE 12 habe ich den invalid command \NFehler durch Erhöhen des Speicherplatzes behoben . Der Mangel an Speicherplatz verursachte den Fehler für mich. Sie können feststellen, ob Sie nicht genügend Speicherplatz haben, wenn Sie sich das Dateisystem ansehen, in das Ihre Daten in der df -hAusgabe verschoben werden. Wenn das Dateisystem / Mount zu 100% verwendet wird, müssen Sie wahrscheinlich den verfügbaren Speicherplatz erhöhen , nachdem Sie Folgendes getan haben psql -f db.out postgres(siehe https://www.postgresql.org/docs/current/static/app-pg-dumpall.html ) .


0

Ich hatte das gleiche Problem, ich habe eine neue Datenbank erstellt und invalid command \Nmit psql wiederhergestellt. Ich habe es gelöst, indem ich den gleichen Tabellenbereich mit der alten Datenbank festgelegt habe.

Zum Beispiel hatte die alte Datenbanksicherung den Tabellenbereich "pg_default", ich habe den gleichen Tabellenbereich für die neue Datenbank definiert und der obige Fehler ist verschwunden!

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.