On 29.01.2013 02:07, Simon Riggs wrote:
+ /*
+ * If we've been explicitly promoted with fast option,
+ * end of recovery without a checkpoint if possible.
+ */
+ if (fast_promote)
+ {
+ checkPointLoc = ControlFile->prevCheckPoint;
+ record = ReadCheckpointRecord(xlogreader,
checkPointLoc, 2, false);
+ if (record != NULL)
+ {
+ checkpoint_wait = false;
+ CreateEndOfRecoveryRecord();
+ }
+ }
If we must have this ReadCheckPointRecord check, it needs more than zero
comments. Also, if it ever fails for some reason, I'd like to have a big
fat warning in the log to caution that something went badly wrong.
Why does it insist that we still have not only the latest checkpoint,
but the previous one too? At recovery, we fall back to the previous
checkpoint if we can't access the latest one, but that's just a
desperate measure to try to recover something if things have gone badly
wrong. It's OK to not have the WAL containing the previous checkpoint
still around. In particular, right after restoring from a base backup,
e.g with pg_basebackup -x, or with good old pg_start/stop_backup, the
WAL included with the backup won't stretch back to previous checkpoint.
- Heikki
--
Sent via pgsql-committers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
