为什么 pg_dumpall 会抛出“OID 不存在”错误？

Question

当我跑步时，pg_dumpall我现在得到了这个：

$ pg_dumpall -f may2012
pg_dump: schema with OID 7549789 does not exist
pg_dumpall: pg_dump failed on database "dealermade", exiting

我该如何解决？

更新

以下是@depesz 请求的一些数据：

select relname from pg_class where relnamespace = 7549789;
   relname    
--------------
 lotdata
 lotdata_pkey
(2 rows)

Answer 1

做：

select * from pg_class where relnamespace = 7549789;

和：

select * from pg_proc where pronamespace = 7549789;

这些是最有可能的嫌疑人（还有其他可能与模式相关的对象）。

确保在dealermade 数据库中运行查询。

在您看到结果之后 - 答案可能很明显（例如：从 ... where .. 删除），或者更棘手 - 取决于坏对象是什么。但至少你会有一些数据。

另外 - 尝试启用所有查询的日志记录，然后重新运行 pg_dump 以查看失败的确切查询是什么。

Answer 2

多年来，这一问题已被多次报道，但根本原因从未真正确定。似乎很清楚的一件事是，它是在删除模式时引起的，但对它的某些引用却不是。有证据表明，至少在某些情况下，这是为用户的临时表创建的“特殊”模式。

传统的修复方法是以数据库超级用户身份登录，并从系统表中删除对架构的延迟引用。pg_depend 和 pg_type 似乎是找到这些的主要表。有些人喜欢创建一个模式并更新其 oid 以匹配缺失的模式，然后先进行探索，但我还没有看到这会产生太多附加信息或恢复任何数据。

这可能不相关，但可能是一条线索：我对“每当你做任何重大事情时你”的说法感到担忧VACUUM FULL ANALYZE。这是什么版本？您是针对整个数据库还是仅针对特定表运行它？之后您会重新索引吗？一般来说，真空完全应该被认为是一种非常积极的维护形式，只有在出现问题时才需要。

如果您认为您有证据证明问题的原因，请与 PostgreSQL 社区分享，以便我们修复它。到目前为止，还没有人提出可重复的测试案例或提供足够的法医证据来追踪它，而且这种情况很少见，很难发现。如果您有证据，可以先发送电子邮件至 pgsql-general@postgresql.org。