当尝试创建尚不存在的函数表时，PG_Restore会失败

Question

我已经使用 pg_dump --no-privileges --format custom --compress=0 some_database > my-dump.pgdump倾倒数据库，但是当我尝试还原时，我会遇到问题。

具体来说，它似乎是在表定义之前加载函数定义：

$ pg_restore ./my-dump.pgdump
…
create function my_function() returns …
language sql $$
  select …
  from some_table
  where …
$$;
… later in the dump …
create table some_table ( … );
…

当我尝试恢复转储时会导致错误：

pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 4863; 0 16735 TABLE DATA some_table some_database
pg_restore: [archiver (db)] COPY failed for table "some_table": ERROR:  relation "some_table" does not exist
LINE 3:                     from some_table
                                 ^
QUERY:
                    select …
                    from some_table
                    where …
CONTEXT:  SQL function "my_function" during inlining

这里发生了什么？我如何欺骗pg_dump/pg_restore以正确的顺序做事？

Answer 1

检查您的转储文件是否与search_path混乱的命令，例如：

SELECT pg_catalog.set_config('search_path', '', false);

我在我继承的旧版项目中遇到与您(关系xxx不存在的(，即使它正在运行PostgreSQL 9.4.x。

，

我将其追溯到上述命令。

解决方案是从转储文件中删除此命令。

完成此操作后，我能够在没有错误的情况下还原数据库。

Answer 2

注意：OP使用自定义格式。没有发出的二进制文件编辑。

根据我的经验，使用自定义格式(-FC(的PG_DUMP未设置check_function_bodies = false。但是，由于它在转储文件的顶部添加了随机函数(而不是将所有例程放在末尾(，因此会导致pg_restore到barf。

我能够通过设置pgoptions解决这个问题：

export PGOPTIONS="-c check_function_bodies=false"
pg_restore ...

Answer 3

这很奇怪。自从提交EF88199F611E625B496FF92AA17A17A447D254B9796以来，pg_dump和pg_restore已发出

SET check_function_bodies = false;

此设置确保像您描述的错误不会发生，因为PostgreSQL不会检查功能体的有效性。

您是在使用古老的PostgreSQL版本，还是在做其他可能会搞砸的事情？

如果您在转储上运行pg_restore(无需指定目标数据库(，是否会发出行？