psql nieprawidłowe polecenie \ N podczas przywracania sql

146

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.

Vivek Vikranth
źródło

Odpowiedzi:

209

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
Pavel Stehule
źródło
7
Tak, bardzo, bardzo łatwy błąd do popełnienia, ponieważ liczba tych błędów nieprawidłowych poleceń może być bardzo duża, całkowicie przesłaniając pierwszy błąd, który wystąpił na początku.
crowmagnumb
6
To dość złe ze strony PostgreSQL dawanie tak mylącego ostrzeżenia, twoja odpowiedź zaoszczędziła mi dużo czasu!
Tregoreg,
52
@Tregoreg - tak, nie jest przyjazny - możesz uruchomić psql w trybie „zatrzymaj się przy pierwszym błędzie”. Upraszcza diagnostykę „psql -v ON_ERROR_STOP = 1”
Pavel Stehule,
2
Może się zdarzyć, gdy np. Nie create table...powiedzie się na starcie, ale ładowanie jest kontynuowane.
JaakL
1
Przyjechałem tu z powodu tego samego błędu. Doszedłem do wniosku: (pg_restore ... | psql ...) 2>&1 | less
THK
36

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
Steve K.
źródło
także znacznie niższe zużycie procesora, prawda?
catbadger
16

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

So4ne
źródło
1
Co za uratowanie życia!
matmat
8

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.

oraserrata
źródło
„Nie mam jeszcze zainstalowanego rozszerzenia„ hstore ””, TNX.
iRhonin
7

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

João Neves Filho
źródło
2
To działa dla mnie! pg_dump --inserts $ DATABASE> $ NAZWA PLIKU
Abel
4

Zainstaluj postgresql- (twoja wersja) -postgis-scripts

Geets
źródło
4

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.

Ekrem Gurdal
źródło
2

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.

cognalog
źródło
1

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

Farsheed
źródło
0

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 .

alpinista11
źródło
0

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ął!

John Makridis
źródło
0

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;
Jeremy Thompson
źródło
0

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.

Felipe Valdes
źródło