关于pg_restore删库及template1处理的技术疑问

1. pg_dump未加--clean但pg_restore启用该选项的影响 #

分两种备份格式场景说明：

• 自定义/目录/归档格式（如pg_dump -Fc）：pg_restore会在创建每个对象（表、函数、序列等）前，自动生成并执行DROP ... IF EXISTS命令。如果目标库中不存在对应对象，会输出警告但不中断恢复；如果对象存在且有未解除的依赖（比如外键关联、视图依赖），DROP操作会失败，直接终止恢复流程。
• 纯SQL格式备份：pg_restore的--clean选项完全无效，因为SQL备份文件中没有预先生成的DROP逻辑，pg_restore仅按顺序执行文件内的SQL语句，不会额外添加删除操作。

2. pg_upgrade生成的dump文件中出现删除postgres库的原因 #

pg_upgrade在跨版本升级集群时，需要保证目标集群的postgres数据库与原集群完全一致。目标集群默认的postgres库是初始化时生成的空库（仅含系统对象），而原集群的postgres可能包含用户自定义的表、函数等对象。因此pg_upgrade会先删除目标集群的postgres库，再从原集群恢复完整的postgres库内容。

另外，pg_upgrade执行此操作时，是连接到template1数据库进行的，所以删除postgres库不会影响当前连接的稳定性。

3. template1数据库的具体处理逻辑 #

PostgreSQL对template1的处理逻辑围绕“避免删除恢复连接依赖的库”展开：

• 未指定--clean时：pg_restore不会删除目标环境的template1，仅将备份中template1的自定义对象（如扩展、函数、表结构）合并恢复到目标template1中，保留原template1的系统基础结构。
• 指定--clean时：pg_dump会生成删除template1的SQL语句，但pg_restore执行时会自动切换连接到template0（只读系统模板，始终存在且不会被删除），先删除目标环境的template1，再重新创建template1并从备份恢复完整内容。这种连接切换是自动完成的，不会出现“连接到要删除的template1”的冲突问题。

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