PostgreSQL迁移时pg_dumpall执行REFRESH MATERIALIZED VIEW报错的原因及疑问

报错原因 #

核心问题是执行上下文不匹配：

• pg_dumpall默认先连接到postgres系统库执行全局对象（如角色、表空间）的恢复，之后才处理用户数据库的对象。
• 你的unaccent(text)函数（属于unaccent扩展）和banners_text_search物化视图都存放在mydb用户库中。当恢复流程在postgres库上下文执行REFRESH MATERIALIZED VIEW banners_text_search时，postgres库既没有安装unaccent扩展，也不存在这个物化视图，因此触发"对象不存在"的报错。
• 手动添加\connect mydb后，恢复流程切换到目标库上下文，函数和物化视图都处于当前生效的数据库中，刷新操作自然能正常执行。

为什么pg_dumpall不会自动生成\connect mydb语句 #

pg_dumpall的恢复逻辑是分阶段设计的：

1. 先恢复全局共享对象（角色、表空间、配置参数等），这部分固定在postgres库执行，无需切换数据库。
2. 对每个用户数据库，它会自动生成CREATE DATABASE mydb; + \connect mydb;的语句块，随后在该库上下文恢复所有库内对象（包括扩展、表、物化视图等）。

你遇到的情况，大概率是REFRESH MATERIALIZED VIEW语句被错误放在了全局恢复阶段（而非mydb的专属恢复块内），导致pg_dumpall没有为其自动添加切换指令。常见触发场景包括：

• 物化视图依赖跨库对象，pg_dumpall无法自动识别其归属库；
• 手动修改过dump文件，打乱了原有的语句顺序；
• 特殊对象配置导致pg_dumpall生成的脚本上下文出现偏差。

内容的提问来源于stack exchange，提问作者Eugen Konkov