我试图恢复我的转储文件,但它导致了一个错误:
psql:psit.sql:27485: invalid command \N
有解决办法吗?我找了,但没有得到明确的答案。
我试图恢复我的转储文件,但它导致了一个错误:
psql:psit.sql:27485: invalid command \N
有解决办法吗?我找了,但没有得到明确的答案。
当前回答
对于我在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),您可能需要增加可用的磁盘空间。
其他回答
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.
大多数时候,解决方案是安装postgres-contrib包。
Postgres使用\N作为NULL值的替代符号。但是所有psql命令都以反斜杠\符号开始。当复制语句失败,但转储的加载仍在继续时,您可以获得这些消息。这条消息是假警报。如果希望看到COPY语句失败的真正原因,则必须搜索此错误之前的所有行。
可以切换psql到“第一个错误停止”模式,并找到错误:
psql -v ON_ERROR_STOP=1
我有同样的问题,我创建了一个新的数据库,并得到无效的命令\N恢复与psql。 我通过设置与旧数据库相同的表空间来解决这个问题。
例如,旧数据库备份有表空间“pg_default”,我给新数据库定义了相同的表空间,上面的错误已经消失了!
安装postgresql-(你的版本)-postgis-scripts