我遵循了所有这些例子，它们都失败了，出现了我们正在谈论的错误:

在Postgres中将一个表从一个数据库复制到另一个数据库

有效的是使用-C的语法，请看这里:

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

此外，如果两者之间有不同的模式，我发现改变一个dB的模式以匹配其他的表副本是必要的，例如:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;

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

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

psql -v ON_ERROR_STOP=1

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

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

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

我知道这是一个旧帖子，但我遇到了另一个解决方案:postgis没有安装在我的新版本上，这导致我在pg_dump上出现同样的错误

我遵循了所有这些例子，它们都失败了，出现了我们正在谈论的错误:

在Postgres中将一个表从一个数据库复制到另一个数据库

有效的是使用-C的语法，请看这里:

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

此外，如果两者之间有不同的模式，我发现改变一个dB的模式以匹配其他的表副本是必要的，例如:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;

当我试图从二进制pg_dump恢复时，我收到了相同的错误消息。我简单地使用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