- Notifications
You must be signed in to change notification settings - Fork5
Commitabf5c5c
committed
If recovery.conf is created after "pg_ctl stop -m i", do crash recovery.
If you create a base backup using an atomic filesystem snapshot, and try toperform PITR starting from that base backup, or if you just kill a masterserver and create recovery.conf to put it into standby mode, we don't knowhow far we need to recover before reaching consistency. Normally in crashrecovery, we replay all the WAL present in pg_xlog, and assume that we'reconsistent after that. And normally in archive recovery, minRecoveryPoint,backupEndRequired, or backupEndPoint is set in the control file, indicatinghow far we need to replay to reach consistency. But if the server waspreviously up and running normally, and you kill -9 it or take an atomicfilesystem snapshot, none of those fields are set in the control file.The solution is to perform crash recovery first, replaying all the WAL inpg_xlog. After that's done, we assume that the system is consistent like innormal crash recovery, and switch to archive recovery mode after that.Per report from Kyotaro HORIGUCHI. In his scenario, recovery.conf wascreated after "pg_ctl stop -m i". I'm not sure we need to support that exactscenario, but we should support backing up using a filesystem snapshot,which looks identical.This issue goes back to at least 9.0, where hot standby was introduced andwe started to track when consistency is reached. In 9.1 and 9.2, we wouldopen up for hot standby too early, and queries could briefly see aninconsistent state. But 9.2 made it more visible, as we started to PANIC ifwe see a reference to a non-existing page during recovery, if we've alreadyreached consistency. This is a fairly big patch, so back-patch to 9.2 only,where the issue is more visible. We can consider back-patching further afterthis has received some more testing in 9.2 and master.1 parenta730183 commitabf5c5c
1 file changed
+179
-78
lines changed0 commit comments
Comments
(0)