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.
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.
Réponses:
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
create table...
échoue au démarrage, mais le chargement continue.
(pg_restore ... | psql ...) 2>&1 | less
Je vais le même message d'erreur en essayant de restaurer à partir d'un vidage binaire. J'ai simplement utilisé pg_restore
pour restaurer mon vidage et éviter complètement les \N
erreurs, 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
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:
pg_restore
--table=orders full_database.dump > orders.dump
)orders.dump
et supprimer un tas d'enregistrements)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.
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' -a
option , 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_name
pour peupler schema2.table_name
. La modification manuelle du vidage était facile, le schéma est spécifié dans les 15 premières lignes environ.
Pour moi, en utilisant postgreSQL 10 sur SUSE 12, j'ai résolu l' invalid command \N
erreur 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 -h
sortie. 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 \N
restauration 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;