psql nieprawidłowe polecenie \ N podczas przywracania sql

Próbuję przywrócić plik zrzutu, ale spowodowało to błąd:

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

Czy jest jakieś rozwiązanie? Szukałem, ale nie otrzymałem jasnej odpowiedzi.

Postgres używa "\ N" jako symbolu zastępującego wartość NULL. Ale wszystkie polecenia psql zaczynają się od symbolu "" ukośnika odwrotnego. Możesz otrzymać te komunikaty, gdy instrukcja copy nie powiedzie się, ale ładowanie zrzutu jest kontynuowane. Ta wiadomość to fałszywy alarm. Musisz przeszukać wszystkie wiersze poprzedzające ten błąd, jeśli chcesz zobaczyć prawdziwy powód niepowodzenia instrukcji COPY.

Czy można przełączyć psql w tryb „zatrzymaj się przy pierwszym błędzie” i znaleźć błąd:

psql -v ON_ERROR_STOP=1

Otrzymałem ten sam komunikat o błędzie podczas próby przywrócenia z pliku binarnego pg_dump. Po prostu pg_restoreprzywracałem swój zrzut i całkowicie unikałem \Nbłędów, np

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

Objaśnienie przełączników:

-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

Wiem, że to stary post, ale natknąłem się na inne rozwiązanie: postgis nie był zainstalowany w mojej nowej wersji, co spowodowało ten sam błąd na pg_dump

Również w przeszłości spotkałem się z tym błędem. Paweł ma rację, zwykle jest to znak, że coś w skrypcie stworzonym przez pg_restore nie działa. Z powodu wszystkich błędów „/ N” nie widzisz prawdziwego problemu na samej górze wyniku. Sugeruję:

1. wstawianie pojedynczego, małego stolika (np. pg_restore --table=orders full_database.dump > orders.dump)
2. jeśli nie masz małego, usuń kilka rekordów ze skryptu przywracania - po prostu upewniłem się, że ./ był ostatnim wierszem do załadowania (np. otwórz orders.dumpi usuń kilka rekordów)
3. obserwuj standardowe wyjście, a gdy znajdziesz problem, zawsze możesz porzucić tabelę i załadować ponownie

W moim przypadku nie miałem jeszcze zainstalowanego rozszerzenia „hstore”, więc skrypt na samej górze zawodził. Zainstalowałem hstore w docelowej bazie danych i wróciłem do biznesu.

Możesz wygenerować zrzut za pomocą instrukcji INSERTS, z parametrem --inserts.

Zainstaluj postgresql- (twoja wersja) -postgis-scripts

To samo spotkało mnie dzisiaj. Rozwiązałem problem, zrzucając polecenie --inserts.

Co robię to:

1) pg_dump z wstawkami:

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

2) psql (przywróć zrzucony plik)

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

Uwaga-1) Upewnij się, że dodanie pliku wyjściowego przyspieszy import.

Uwaga-2) Nie zapomnij utworzyć tabeli z dokładnie taką samą nazwą i kolumnami przed zaimportowaniem za pomocą psql.

Z mojego niedawnego doświadczenia wynika, że ​​ten błąd może wystąpić, gdy prawdziwy problem nie ma nic wspólnego ze znakami ucieczki lub znakami nowej linii. W moim przypadku, miałem stworzony zrzut z bazy A z
pg_dump -a -t table_name > dump.sql
i starał się przywrócić go do bazy B z
psql < dump.sql(po aktualizacji odpowiedni env Vars, oczywiście)
Co ja w końcu zorientowali się, że wysypisko, choć było data-only(The -aopcja , aby struktura tabeli nie była jawnie częścią zrzutu), była specyficzna dla schematu. Oznaczało to, że bez ręcznej modyfikacji zrzutu nie mogłem użyć zrzutu wygenerowanego z schema1.table_namedo wypełnienia schema2.table_name. Ręczna modyfikacja zrzutu była łatwa, schemat jest określony w pierwszych 15 wierszach lub więcej.

W większości przypadków rozwiązaniem jest zainstalowanie postgres-contribpakietu.

Używając PostgreSQL 10 na SUSE 12, rozwiązałem ten invalid command \Nbłąd, zwiększając miejsce na dysku. Brak miejsca na dysku był przyczyną błędu. Możesz stwierdzić, czy zabrakło miejsca na dysku, patrząc na system plików, do którego dane mają trafić w df -hwyniku. Jeśli system plików / montowanie jest w 100% wykorzystane, po zrobieniu czegoś takiego psql -f db.out postgres(zobacz https://www.postgresql.org/docs/current/static/app-pg-dumpall.html ) prawdopodobnie będziesz musiał zwiększyć dostępne miejsce na dysku .

Miałem ten sam problem, utworzyłem nową bazę danych i rozpocząłem invalid command \Nprzywracanie z psql. Rozwiązałem to, ustawiając ten sam obszar tabel ze starą bazą danych.

Na przykład stara kopia zapasowa bazy danych miała obszar tabel „pg_default”, zdefiniowałem ten sam obszar tabel w nowej bazie danych i powyższy błąd zniknął!

Podążałem za wszystkimi tymi przykładami i wszystkie zawiodły z błędem, o którym mówimy:

Skopiuj tabelę z jednej bazy danych do drugiej w Postgres

To, co zadziałało, to składnia z -C , patrz tutaj:

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

Również jeśli między nimi istnieją różne schematy, uważam, że zmiana schematu jednego dB w celu dopasowania innych jest konieczna, aby kopie tabeli działały, np .:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;

Moje rozwiązanie było takie:

psql -U your_user your_db < your.file.here.sql  2>&1|more

w ten sposób mogłem odczytać komunikat o błędzie

Mam nadzieję, że to komuś pomoże.