commande psql invalide \ N lors de la restauration de sql

137

J'essaie de restaurer mon fichier de vidage, mais cela a causé une erreur:

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

Y a-t-il une solution? J'ai cherché, mais je n'ai pas obtenu de réponse claire.

Vivek Vikranth
la source

Réponses:

198

Postgres utilise "\ N" comme symbole de substitution pour la valeur NULL. Mais toutes les commandes psql commencent par une barre oblique inverse "\". Ainsi, vous pouvez obtenir ces messages, lorsque l'instruction de copie échoue probablement, mais qu'un chargement de vidage se poursuit. Ce message n'est qu'une fausse alarme. Vous devez rechercher une ligne avant la raison pour laquelle l'instruction COPY échoue.

Il est possible de basculer psql en mode «arrêt à la première erreur» et de rechercher une erreur:

psql -v ON_ERROR_STOP=1
Pavel Stehule
la source
7
Oui, une erreur très, très facile à faire car le nombre de ces erreurs de commande non valides peut être extrêmement important, masquant complètement la première erreur rencontrée au début.
crowmagnumb
5
C'est assez diabolique de la part de PostgreSQL de donner un avertissement aussi trompeur, votre réponse m'a fait gagner beaucoup de temps!
Tregoreg
50
@Tregoreg - oui, ce n'est pas convivial - vous pouvez exécuter psql en mode "arrêt à la première erreur". Cela simplifie les diagnostics "psql -v ON_ERROR_STOP = 1"
Pavel Stehule
2
Peut se produire lorsque, par exemple, create table...échoue au démarrage, mais le chargement continue.
JaakL
1
Je suis venu ici à cause de la même erreur. Ce que j'ai compris était de faire: (pg_restore ... | psql ...) 2>&1 | less
THK
33

Je vais le même message d'erreur en essayant de restaurer à partir d'un vidage binaire. J'ai simplement utilisé pg_restorepour restaurer mon vidage et éviter complètement les \Nerreurs, par exemple

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

Explication des commutateurs:

-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

Steve K
la source
également une utilisation beaucoup plus faible du processeur, n'est-ce pas?
catbadger
15

Je sais que c'est un ancien message mais je suis tombé sur une autre solution: postgis n'était pas installé sur ma nouvelle version, ce qui m'a causé la même erreur sur pg_dump

So4ne
la source
1
Quel sauveur de vie!
matmat
8

J'ai également rencontré cette erreur dans le passé. Pavel a raison, c'est généralement le signe que quelque chose dans le script créé par pg_restore échoue. En raison de toutes les erreurs "/ N", vous ne voyez pas le vrai problème tout en haut de la sortie. Je suggère:

  1. insérer une seule petite table (par exemple pg_restore --table=orders full_database.dump > orders.dump)
  2. si vous n'en avez pas un petit, supprimez un tas d'enregistrements du script de restauration - je me suis juste assuré que le ./ était la dernière ligne à charger (par exemple, ouvrez orders.dump et supprimer un tas d'enregistrements)
  3. regardez la sortie standard, et une fois que vous trouvez le problème, vous pouvez toujours supprimer la table et recharger

Dans mon cas, je n'avais pas encore installé l'extension "hstore", donc le script échouait tout en haut. J'ai installé hstore sur la base de données de destination et j'étais de retour dans les affaires.

oraserrata
la source
"Je n'avais pas encore installé l'extension" hstore "", TNX.
Arash Fatahzade le
7

Vous pouvez générer votre vidage à l'aide d'instructions INSERTS, avec le paramètre --inserts.

João Neves Filho
la source
2
Cela fonctionne pour moi! pg_dump --inserts $ DATABASE> $ FILENAME
Abel
4

Installez postgresql- (votre version) -postgis-scripts

Geets
la source
4

La même chose m'est arrivée aujourd'hui. J'ai géré le problème en vidant avec la commande --inserts.

Ce que je fais c'est:

1) pg_dump avec inserts:

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

2) psql (restaurez votre fichier sauvegardé)

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

Note-1) Assurez-vous que l'ajout d'un fichier de sortie augmentera la vitesse d'importation.

Note-2) N'oubliez pas de créer une table avec exactement le même nom et les mêmes colonnes avant d'importer avec psql.

Ekrem Gurdal
la source
2

Dans mon expérience récente, il est possible d'obtenir cette erreur lorsque le vrai problème n'a rien à voir avec les caractères d'échappement ou les retours à la ligne. Dans mon cas, j'avais créé un vidage de la base de données A avec
pg_dump -a -t table_name > dump.sql
et j'essayais de le restaurer dans la base de données B avec
psql < dump.sql(après avoir mis à jour les variables d'environnement appropriées, bien sûr)
Ce que j'ai finalement compris, c'est que le vidage, bien qu'il soit data-only(l' -aoption , de sorte que la structure de la table ne fait pas explicitement partie du vidage), était spécifique au schéma. Cela signifiait que sans modifier manuellement le vidage, je ne pouvais pas utiliser un vidage généré à partir de schema1.table_namepour peupler schema2.table_name. La modification manuelle du vidage était facile, le schéma est spécifié dans les 15 premières lignes environ.

Tyrone Hinderson
la source
1

La plupart du temps, la solution consiste à installer le postgres-contribpackage.

Farsheed
la source
0

Pour moi, en utilisant postgreSQL 10 sur SUSE 12, j'ai résolu l' invalid command \Nerreur en augmentant l'espace disque. Le manque d'espace disque était à l'origine de l'erreur pour moi. Vous pouvez dire si vous manquez d'espace disque si vous regardez le système de fichiers vers lequel vos données vont dans la df -hsortie. Si le système de fichiers / montage est utilisé à 100%, après avoir fait quelque chose comme psql -f db.out postgres(voir https://www.postgresql.org/docs/current/static/app-pg-dumpall.html ), vous devrez probablement augmenter l'espace disque disponible .

alpiniste
la source
0

J'ai eu le même problème, j'ai créé une nouvelle base de données et j'ai commencé la invalid command \Nrestauration avec psql. Je l'ai résolu en définissant le même tablespace avec l'ancienne base de données.

Par exemple, l'ancienne sauvegarde de la base de données avait un tablespace "pg_default", j'ai défini le même tablespace dans la nouvelle base de données et l'erreur ci-dessus a disparu!

John Makridis
la source
0

J'ai suivi tous ces exemples et ils ont tous échoué avec l'erreur dont nous parlons:

Copier une table d'une base de données à une autre dans Postgres

Ce qui a fonctionné était la syntaxe avec -C , voir ici:

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

De plus, s'il y a des schémas différents entre les deux, je trouve que modifier le schéma d'un dB pour qu'il corresponde aux autres est nécessaire pour que les copies de table fonctionnent, par exemple:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;
Jeremy Thompson
la source