Re: pgsql: Fast promote mode skips checkpoint at end of recovery.

On 29 January 2013 11:31, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> 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.

As you say, there are cases where the lack of a secondary checkpoint
could be considered normal, hence no message to confuse the user.

We don't actually need a fast promotion when restoring from backup, so
we don't do it.

I want this to work for the cases we need it, and not break when we
don't need it.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services