SQLの復元中にpsqlが無効なコマンド\ N

ダンプファイルを復元しようとしていますが、エラーが発生しました。

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

解決策はありますか？検索したのですが、はっきりとした答えが得られませんでした。

PostgresはNULL値の代替記号として「\ N」を使用します。ただし、すべての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. 小さいレコードがない場合は、復元スクリプトから一連のレコードを削除します-./がロードされる最後の行であることを確認しました（たとえば、open 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を更新した後はもちろん、varsは）
私は最終的に考え出したそれは何だったのに、というダンプた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"

また、2つのスキーマが異なる場合、テーブルのコピーが機能するためには、1 dBのスキーマを他のスキーマと一致させるよう変更する必要があります。たとえば、

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;