commande psql invalide \ N lors de la restauration de sql

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.

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

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

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

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.

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

Installez postgresql- (votre version) -postgis-scripts

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.

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.

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

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 .

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!

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;