Я пытаюсь восстановить файл дампа, но это вызвало ошибку:
psql:psit.sql:27485: invalid command \N
Есть ли решение? Я искал, но не получил внятного ответа.
Я пытаюсь восстановить файл дампа, но это вызвало ошибку:
psql:psit.sql:27485: invalid command \N
Есть ли решение? Я искал, но не получил внятного ответа.
Ответы:
Postgres использует "\ N" как заменяющий символ для значения NULL. Но все команды psql начинаются с символа обратной косой черты "\". Таким образом, вы можете получить это сообщение, когда, вероятно, оператор копирования не работает, но загрузка дампа продолжается. Это сообщение является ложной тревогой. Вы должны выполнить поиск в строке раньше, чтобы выяснить, почему оператор COPY не работает.
Можно переключить psql в режим «останавливать при первой ошибке» и найти ошибку:
psql -v ON_ERROR_STOP=1
create table...
при запуске произошел сбой, но загрузка продолжается.
(pg_restore ... | psql ...) 2>&1 | less
Такое же сообщение об ошибке появляется при попытке восстановления из двоичного дампа. Я просто 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
Я тоже сталкивался с этой ошибкой в прошлом. Павел прав, обычно это признак того, что что-то в скрипте, созданном pg_restore, не работает. Из-за всех ошибок «/ N» вы не видите реальной проблемы в самом начале вывода. Я предлагаю:
pg_restore
--table=orders full_database.dump > orders.dump
)orders.dump
и удалить кучу записей)В моем случае у меня еще не было установлено расширение "hstore", поэтому скрипт давал сбой на самом верху. Я установил hstore в целевую базу данных и вернулся к работе.
Вы можете сгенерировать дамп с помощью операторов INSERTS с параметром --inserts.
То же самое случилось со мной сегодня. Я решил проблему, выполнив сброс с помощью команды --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 строках или около того.
Для меня, использующего 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;