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 по дате отправления: