PostgreSQL恢复期间数据库是否可访问？pg_restore自定义格式恢复问询

让我把你关心的几个关键点拆解清楚，帮你理清pg_restore恢复过程中的访问控制和数据一致性问题：

1. 默认恢复模式下，数据库是可访问的，但风险极大 #

当你用pg_restore（自定义格式备份）恢复到已存在的数据库时，默认是允许普通客户端连接并执行插入、修改等写操作的。但这么做会直接破坏数据一致性：

• pg_restore默认会分步骤执行恢复（比如先建表、导数据，再创索引），每一步都是独立的小事务，没有原子性保障。
• 如果客户端在恢复期间往正在导入的表插入数据，最终表中会同时存在备份数据和新写入的数据，完全偏离你恢复备份的初衷。
• 这些客户端的更改不会被自动清除，会永久留在恢复后的数据库里，造成数据污染。

2. --single-transaction：给恢复加上原子性，但仍需谨慎 #

如果你给pg_restore加上--single-transaction参数，整个恢复流程会被包裹在一个大事务里，这时候：

• 恢复操作具备原子性：要么全部成功提交，要么全部回滚，不会出现半拉子恢复的状态。
• 其他客户端可以读取数据库（基于恢复开始前的快照），但针对恢复中对象的写操作会被阻塞，直到恢复事务完成（提交或回滚）。
• 如果恢复事务成功提交，备份数据会成为数据库的最新状态，但如果恢复期间客户端有写入冲突（比如修改了pg_restore要重建的表），会直接导致恢复失败。
• 如果恢复事务回滚，客户端在恢复期间的写入操作会保留（因为它们是独立的事务）。

3. 最佳实践：恢复期间一定要阻止普通客户端访问 #

不管你用不用--single-transaction，都强烈建议在恢复期间限制普通客户端的访问，避免不必要的麻烦。这里有几个简单可行的方法：

• 限制连接数：用超级用户执行ALTER DATABASE your_target_db CONNECTION LIMIT 0;，这样只有超级用户能连，普通客户端会被拒绝。恢复完成后改回CONNECTION LIMIT -1（无限制）。
• 临时调整权限配置：修改pg_hba.conf，注释掉针对目标数据库的客户端连接规则，然后执行pg_ctl reload让配置生效。恢复完再改回去。
• 设置数据库只读：执行ALTER DATABASE your_target_db SET default_transaction_read_only = true;，普通客户端只能读不能写，恢复完成后再设为false。

4. 新数据库恢复的特殊情况 #

如果你是先创建一个空数据库（比如createdb new_db）再恢复，理论上恢复期间可以访问，但完全没必要——数据还没恢复完整，访问没有实际意义，万一不小心写入数据，同样会让最终数据库状态和备份不一致。

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