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-скриптів

Те саме трапилося і зі мною сьогодні. Я вирішував питання, скидаючи команду --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.

З мого недавнього досвіду, можна отримати цю помилку, коли реальна проблема не має нічого спільного з символами втечі або новими рядками. У моєму випадку я створив дамп із бази даних A
pg_dump -a -t table_name > dump.sql
і намагався відновити його в базі даних B
psql < dump.sql(після оновлення належних середовищ, звичайно).
Я нарешті з'ясував, що це дамп, хоч і був data-only( -aопція , так що структура таблиці явно не є частиною дампа), була специфічною для схеми. Це означало, що без зміни вручну дампа я не можу використовувати дамп, створений schema1.table_nameдля заповнення schema2.table_name. Вручну змінити дамп було легко, схема вказана в перших 15 рядках або близько того.

У більшості випадків рішення - встановити postgres-contribпакет.

Для мене, використовуючи 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

Що спрацював синтаксис з -С , дивіться тут:

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

Крім того, якщо між двома схемами існують різні схеми, я вважаю, що для того, щоб копії таблиці працювали, потрібно змінити схему одного dB, щоб відповідати іншим, наприклад:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;