Re: Enforcing that all WAL has been replayed after restoring from backup - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Enforcing that all WAL has been replayed after restoring from backup
Date
Msg-id 4E41509D.3090408@enterprisedb.com
Whole thread Raw
In response to Re: Enforcing that all WAL has been replayed after restoring from backup  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Enforcing that all WAL has been replayed after restoring from backup
List pgsql-hackers
On 09.08.2011 18:20, Alvaro Herrera wrote:
> Excerpts from Heikki Linnakangas's message of mar ago 09 05:00:00 -0400 2011:
>
>> I think this is a nice additional safeguard to have, making streamed
>> backups more robust. I'd like to add this to 9.1, but it required an
>> extra field to be added to the control file, so it would force an
>> initdb. It's probably not worth that. Or, we could sneak in the extra
>> boolean field to some currently unused pad space in the ControlFile struct.
>
> How about making the new backup_label field optional?  If absent, assume
> current behavior.

That's how I actually did it in the patch. However, the problem wrt. 
requiring initdb is not the new field in backup_label, it's the new 
field in the control file.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Enforcing that all WAL has been replayed after restoring from backup
Next
From: Heikki Linnakangas
Date:
Subject: Re: Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)