Re: 9.2.3 crashes during archive recovery

On 16.02.2013 10:40, Ants Aasma wrote:
> On Fri, Feb 15, 2013 at 3:49 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>>> While this solution would help solve my issue, it assumes that the
>>> correct amount of WAL files are actually there. Currently the docs for
>>> setting up a standby refer to "24.3.4. Recovering Using a Continuous
>>> Archive Backup", and that step recommends emptying the contents of
>>> pg_xlog. If this is chosen as the solution the docs should be adjusted
>>> to recommend using pg_basebackup -x for setting up the standby.
>>
>> When the backup is taken using pg_start_backup or pg_basebackup,
>> minRecoveryPoint is set correctly anyway, and it's OK to clear out pg_xlog.
>
> How is minRecoveryPoint supposed to get set?

I was a slightly imprecise. minRecoveryPoint is not set at backup, but
backupStartPoint is. minRecoveryPoint is set later, once the
end-of-backup record is seen. A valid backupStartPoint has the same
effect as minRecoveryPoint: the system is considered inconsistent until
the end-of-backup record is seen.

> I just tried taking a
> pg_basebackup on master running pgbench. The resulting data dir
> controlfile had this:
>
> Min recovery ending location: 0/0
>
> The end location was not in the backup_label either.
>
> Looking at basebackup.c the process seems to be:
> 1. pg_start_backup
> 2. copy out backup_label
> 3. copy out rest of the datadir
> 4. copy out control file
> 5. pg_stop_backup
> 6. copy out WAL
> 7. send backup stop location
>
> And pg_basebackup.c only uses the stop location to decide how much WAL to fetch.
>
> I don't see anything here that could correctly communicate min
> recovery point. Maybe I'm missing something.

backupStartPoint is set, which signals recovery to wait for an
end-of-backup record, until the system is considered consistent. If the
backup is taken from a hot standby, backupEndPoint is set, instead of
inserting an end-of-backup record.

- Heikki