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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Enforcing that all WAL has been replayed after restoring from backup
Дата
Msg-id CA+TgmoYkX=dYJVkrnXLPo8moik-BbrJin-8n7w5RQeU-vN74CA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Enforcing that all WAL has been replayed after restoring from backup  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Aug 10, 2011 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Hmm, that's not possible for the 'tar' output, but would work for 'dir'
>> output. Another similar idea would be to withhold the control file in
>> memory until the end of backup, and append it to the output as last. The
>> backup can't be restored until the control file is written out.
>
>> That won't protect from more complicated scenarios, like if you take the
>> backup without the -x flag, and copy some but not all of the required
>> WAL files manually to the pg_xlog directory. But it'd be much better
>> than nothing for 9.1.
>
> Maybe we're overcomplicating this.  What about changing pg_basebackup to
> print a message when the backup is completely sent/received?  People
> would get used to that quickly, and would know to be suspicious if they
> didn't see it.

Yeah, but would they be sufficiently suspicious to think "oh, my
backup is hopeless corrupted even if it seems to work"?

I think a clearer warning is needed, at the very least, and if there's
a way to prevent it altogether at least in straightforward cases, that
would be even better.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Enforcing that all WAL has been replayed after restoring from backup
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: gcc 4.6 warnings in HEAD?