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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Enforcing that all WAL has been replayed after restoring from backup
Дата
Msg-id 14347.1312998328@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Enforcing that all WAL has been replayed after restoring from backup  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Enforcing that all WAL has been replayed after restoring from backup  (Robert Haas <robertmhaas@gmail.com>)
Re: Enforcing that all WAL has been replayed after restoring from backup  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
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.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Enforcing that all WAL has been replayed after restoring from backup