SQL을 복원하는 동안 psql 잘못된 명령 \ N

덤프 파일을 복원하려고하는데 오류가 발생했습니다.

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

해결책이 있습니까? 나는 검색했지만 명확한 대답을 얻지 못했습니다.

Postgres는 "\ N"을 NULL 값의 대체 기호로 사용합니다. 그러나 모든 psql 명령은 백 슬래시 "\"기호로 시작합니다. 따라서 copy 문이 실패했을 때이 메시지를 얻을 수 있지만 덤프로드는 계속됩니다. 이 메시지는 잘못된 경고 일뿐입니다. 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에서 동일한 오류가 발생했습니다.

과거 에도이 오류가 발생했습니다. Pavel은 정확합니다. 일반적으로 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로 가져 오기 전에 정확히 동일한 이름과 열로 테이블을 작성하는 것을 잊지 마십시오.

최근의 경험에서 실제 문제가 이스케이프 문자 또는 줄 바꿈과 관련이없는 경우이 오류가 발생할 수 있습니다. 내 경우에는, 내가 가진 데이터베이스 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-contrib패키지 를 설치하는 것입니다 .

SUSE 12에서 postgreSQL 10을 사용 invalid command \N하는 경우 디스크 공간을 늘려서 오류를 해결했습니다 . 디스크 공간 부족으로 인해 오류가 발생했습니다. 데이터가 df -h출력 되는 파일 시스템을 보면 디스크 공간이 부족한지 알 수 있습니다 . 파일 시스템 / 마운트가 100 % 사용 된 경우 psql -f db.out postgres( https://www.postgresql.org/docs/current/static/app-pg-dumpall.html 참조 ) 사용 가능한 디스크 공간을 늘려야합니다. .

나는 같은 문제가 있었고, 새로운 데이터베이스를 만들고 invalid command \Npsql로 복원했다. 이전 데이터베이스와 동일한 테이블 공간을 설정하여 해결했습니다.

예를 들어, 이전 데이터베이스 백업에 "pg_default"테이블 스페이스가 있고 새 데이터베이스에 동일한 테이블 스페이스를 정의했으며 위의 오류가 발생했습니다!

나는이 모든 예를 따르고 우리가 이야기하는 오류로 모두 실패했습니다.

Postgres의 한 데이터베이스에서 다른 데이터베이스로 테이블 복사

작동 한 것은 -C 구문입니다 . 여기를 참조하십시오.

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

또한 둘 사이에 다른 스키마가있는 경우 테이블 사본이 작동하려면 다른 dB와 일치하도록 하나의 dB 스키마를 변경해야합니다.

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;