检查表中的列和备份文件中的列是否合适

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

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

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

安装postgresql-(你的版本)-postgis-scripts

In my recent experience, it's possible to get this error when the real problem has nothing to do with escape characters or newlines. In my case, I had created a dump from database A with pg_dump -a -t table_name > dump.sql and was trying to restore it to database B with psql < dump.sql (after updating the proper env vars, of course) What I finally figured out was that the dump, though it was data-only (the -a option, so that the table structure isn't explicitly part of the dump), was schema-specific. That meant that without manually modifying the dump, I couldn't use a dump generated from schema1.table_name to populate schema2.table_name. Manually modifying the dump was easy, the schema is specified in the first 15 lines or so.

当我试图从二进制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

今天我也遇到了同样的事。我通过使用——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导入之前，不要忘记创建具有完全相同名称和列的表。