今天我也遇到了同样的事。我通过使用——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)确保添加outputfile可以提高导入的速度。

注2)在用psql导入之前，不要忘记创建具有完全相同名称和列的表。

大多数时候，解决方案是安装postgres-contrib包。

Postgres使用\N作为NULL值的替代符号。但是所有psql命令都以反斜杠\符号开始。当复制语句失败，但转储的加载仍在继续时，您可以获得这些消息。这条消息是假警报。如果希望看到COPY语句失败的真正原因，则必须搜索此错误之前的所有行。

可以切换psql到“第一个错误停止”模式，并找到错误:

psql -v ON_ERROR_STOP=1

对于我在SUSE 12上使用postgreSQL 10，我通过增加磁盘空间解决了无效命令\N错误。磁盘空间不足导致了我的错误。如果查看df -h输出中数据将要进入的文件系统，就可以判断是否耗尽了磁盘空间。如果文件系统/mount的使用率为100%，在执行类似psql -f db. mount的操作后。对于postgres(请参阅https://www.postgresql.org/docs/current/static/app-pg-dumpall.html)，您可能需要增加可用的磁盘空间。

我过去也遇到过这种错误。Pavel是正确的，这通常是pg_restore创建的脚本中某些东西失败的标志。由于所有的“/N”错误，您在输出的顶部看不到真正的问题。我建议:

插入单个小表(例如，pg_restore . table) ——表full_database =订单。转储>个订单。转储) 如果你没有一个小的，那么从恢复脚本中删除一堆记录-我只是确保./是最后一行被加载(例如，打开订单。转储和删除一堆记录) 观察标准输出，一旦发现问题，就可以随时放弃 表格和重载

在我的情况下，我还没有安装“hstore”扩展，所以脚本在顶部失败。我在目标数据库上安装了hstore，然后就可以继续工作了。

对我来说，与源数据库不同的是ENCODING和LOCALE。 一旦我放弃了目标DB并重新创建它，它就可以正常工作。