On 16.02.2013 10:40, Ants Aasma wrote:
On Fri, Feb 15, 2013 at 3:49 PM, Heikki Linnakangas
<hlinnakan...@vmware.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
