Re: Enforcing that all WAL has been replayed after restoring from backup

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Enforcing that all WAL has been replayed after restoring from backup
Дата
Msg-id 4E41509D.3090408@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Enforcing that all WAL has been replayed after restoring from backup  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Enforcing that all WAL has been replayed after restoring from backup  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Enforcing that all WAL has been replayed after restoring from backup
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Compiler warnings with stringRelOpts (was WIP: Fast GiST index build)