psql недопустимая команда \ N при восстановлении sql

Я пытаюсь восстановить файл дампа, но это вызвало ошибку:

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

Есть ли решение? Я искал, но не получил внятного ответа.

Postgres использует "\ N" как заменяющий символ для значения NULL. Но все команды psql начинаются с символа обратной косой черты "\". Таким образом, вы можете получить это сообщение, когда, вероятно, оператор копирования не работает, но загрузка дампа продолжается. Это сообщение является ложной тревогой. Вы должны выполнить поиск в строке раньше, чтобы выяснить, почему оператор COPY не работает.

Можно переключить psql в режим «останавливать при первой ошибке» и найти ошибку:

psql -v ON_ERROR_STOP=1

Такое же сообщение об ошибке появляется при попытке восстановления из двоичного дампа. Я просто pg_restoreвосстанавливал свой дамп и полностью избегал \Nошибок, например

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

Расшифровка переключателей:

-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

Я знаю, что это старый пост, но я нашел другое решение: postgis не был установлен в моей новой версии, что вызвало у меня ту же ошибку на pg_dump

Я тоже сталкивался с этой ошибкой в ​​прошлом. Павел прав, обычно это признак того, что что-то в скрипте, созданном pg_restore, не работает. Из-за всех ошибок «/ N» вы не видите реальной проблемы в самом начале вывода. Я предлагаю:

1. вставка одной небольшой таблицы (например, pg_restore --table=orders full_database.dump > orders.dump)
2. если у вас нет маленькой, то удалите кучу записей из сценария восстановления - я просто убедился, что ./ была последней загружаемой строкой (например, открытая orders.dump и удалить кучу записей)
3. посмотрите стандартный вывод, и как только вы обнаружите проблему, вы всегда можете удалить таблицу и перезагрузить

В моем случае у меня еще не было установлено расширение "hstore", поэтому скрипт давал сбой на самом верху. Я установил hstore в целевую базу данных и вернулся к работе.

Вы можете сгенерировать дамп с помощью операторов INSERTS с параметром --inserts.

Установите postgresql- (ваша версия) -postgis-scripts

То же самое случилось со мной сегодня. Я решил проблему, выполнив сброс с помощью команды --inserts.

Что я делаю:

1) pg_dump со вставками:

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

2) psql (восстановить ваш дамповый файл)

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

Примечание-1) Убедитесь, что добавление выходного файла увеличит скорость импорта.

Примечание-2) Не забудьте создать таблицу с точно таким же именем и столбцами перед импортом с помощью psql.

По моему недавнему опыту, эту ошибку можно получить, когда настоящая проблема не связана с escape-символами или новой строкой. В моем случае я создал дамп из базы данных A с
pg_dump -a -t table_name > dump.sql
и пытался восстановить его в базу данных B с помощью
psql < dump.sql(после обновления правильных переменных env, конечно). В
конце концов я понял, что дамп, хотя и был data-only( -aвариант , так что структура таблицы явно не является частью дампа), была специфичной для схемы. Это означало, что без изменения дампа вручную я не мог использовать созданный дамп schema1.table_nameдля заполнения schema2.table_name. Изменить дамп вручную было несложно, схема указывается в первых 15 строках или около того.

В большинстве случаев решение заключается в установке postgres-contribpackage.

Для меня, использующего postgreSQL 10 в SUSE 12, я решил invalid command \Nошибку, увеличив дисковое пространство. Недостаток места на диске вызывал ошибку. Вы можете определить, нет ли у вас места на диске, если взглянуть на файловую систему, в которую собираются данные в df -hвыводе. Если файловая система / монтирование используется на 100%, после выполнения чего-то вроде psql -f db.out postgres(см. Https://www.postgresql.org/docs/current/static/app-pg-dumpall.html ) вам, вероятно, потребуется увеличить доступное дисковое пространство ,

У меня была та же проблема, я создал новую базу данных и приступил invalid command \Nк восстановлению с помощью psql. Я решил это, установив то же табличное пространство со старой базой данных.

Например, в старой резервной копии базы данных было табличное пространство «pg_default», я определил то же табличное пространство для новой базы данных, и указанная выше ошибка исчезла!

Я последовал всем этим примерам, и все они потерпели неудачу с ошибкой, о которой мы говорим:

Скопировать таблицу из одной базы данных в другую в Postgres

Сработал синтаксис с -C , см. Здесь:

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

Кроме того, если между ними существуют разные схемы, я считаю, что изменение схемы одного дБ для соответствия другим необходимо для работы копий таблиц, например:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;