恢复 sql 时 psql 无效命令 \N

Question

我正在尝试恢复我的转储文件，但它导致了一个错误：

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

有解决办法吗？ 我搜索了，但我没有得到明确的答案。

Answer 1

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

可以将 psql 切换到“在第一个错误时停止”模式并查找错误：

psql -v ON_ERROR_STOP=1

Answer 2

尝试从二进制 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

Answer 3

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

Answer 4

我过去也遇到过这个错误。 Pavel 是正确的，这通常表明 pg_restore 创建的脚本中的某些内容失败了。 由于所有“/N”错误，您在输出的最顶部看不到真正的问题。 我建议：

1. 插入单个小表（例如， pg_restore --table=orders full_database.dump > orders.dump ）
2. 如果你没有一个小的，那么从恢复脚本中删除一堆记录 - 我只是确保 ./ 是要加载的最后一行（例如，打开orders.dump并删除一堆记录）
3. 观察标准输出，一旦发现问题，随时可以丢表重载

就我而言，我还没有安装“hstore”扩展，所以脚本在最顶端失败。 我在目标数据库上安装了 hstore，然后我又开始营业了。

Answer 5

您可以使用 INSERTS 语句和 --inserts 参数生成转储。

Answer 6

今天同样的事情发生在我身上。 我通过使用 --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

Note-1 ) 确保添加 outputfile 会提高导入速度。

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

Answer 7

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

Answer 8

根据我最近的经验，当真正的问题与转义字符或换行符无关时，可能会出现此错误。 就我而言，我从数据库 A 创建了一个转储
pg_dump -a -t table_name > dump.sql
并试图将其恢复到数据库 B
psql < dump.sql （当然，在更新适当的环境变量之后）
我最终发现转储是特定于模式的，尽管它只是data-only （ -a选项，因此表结构不是转储的明确一部分）。 这意味着如果不手动修改转储，我无法使用从schema1.table_name生成的转储来填充schema2.table_name 。 手动修改转储很容易，模式在前 15 行左右指定。

Answer 9

大多数情况下，解决方案是安装postgres-contrib包。

Answer 10

对于我在 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 ），您可能需要增加可用的磁盘空间。

Answer 11

我遇到了同样的问题，我创建了一个新数据库，并在使用 psql 还原时得到了invalid command \\N 。 我通过使用旧数据库设置相同的表空间来解决它。

例如，旧数据库备份有表空间“pg_default”，我为新数据库定义了相同的表空间，并且上述错误消失了！

Answer 12

我遵循了所有这些示例，但它们都因我们正在谈论的错误而失败：

在 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;

Answer 13

我的解决方案是这样的：

psql -U your_user your_db < your.file.here.sql  2>&1|more

这样我就可以阅读错误信息

我希望这对任何人都有帮助。

Answer 14

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

Answer 15

就我而言，问题是我的目标机器上缺少磁盘空间。 简单地增加本地存储为我修复了它。

希望这有助于某人;)

Answer 16

添加我的决议，以防它帮助任何人。 我安装了 postgis，但错误没有解决。 --inserts 选项不可行，因为我必须复制一个包含数千行表的大模式。 对于同一个数据库，当 pg_dump 和 psql（恢复）在 mac 上运行时，我没有看到这个问题。 但是当 pg_dump 在 linux 机器上运行时，问题出现了，转储文件复制到 mac 并尝试恢复。 所以我在 VSCode 中打开了转储文件。 它检测到异常的线路终止符并提供删除它们的选项。 之后，转储文件恢复运行没有无效命令 \N 错误。

Answer 17

@farshid-ashuri 的答案对我来说很好。

我在 Almalinux 上使用 Postgres 14 并出现类似的消息。 安装 postgresql14-contrib package 后，我恢复了完整的转储，没有更多消息。

*对不起，我的英语很差。

Answer 18

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