Re: Problem with PITR recovery
От | Simon Riggs |
---|---|
Тема | Re: Problem with PITR recovery |
Дата | |
Msg-id | 1113870328.16721.2083.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Problem with PITR recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Problem with PITR recovery
Re: Problem with PITR recovery |
Список | pgsql-hackers |
On Mon, 2005-04-18 at 19:21 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > The wal file could be truncated after the log switch record, though I'd > > want to make sure that didn't cause other problems. > > Which it would: that would break WAL file recycling. Yeh, there's just too many references to the file length for comfort. > > That would be initiated through a single function pg_walfile_switch() > > which would be called from > > 1) pg_stop_backup() > > 2) by user command > > 3) at a specified timeout within archiver (already built in) > > I would really, really, like NOT to have a user command for this. > (If pg_stop_backup does it, that already provides an out for anyone > who thinks they need to invoke it manually.) Actually, me too. Never saw the need for the Oracle command myself. > > A shutdown checkpoint would also have the same effect as an > > XLOG_FILE_SWITCH instruction, so that the archiver would be able to copy > > away the file. > > The archiver is stopped before we do the shutdown, no? Currently, the bgwriter issues the Shutdown checkpoint and the archiver is always stopped after the bgwriter has issued the checkpoint and quit. It should be possible to send archiver a signal to attempt any remaining archiving before shutdown. Of course, this behaviour would only be initiated when XLogArchivingActive() is true, since it makes no sense otherwise. > > I'd suggest this as a backpatch for 8.0.x, when completed. > > Not a chance --- it's a new feature, not a bug fix, and has substantial > risk of breaking things. No problem for me personally; I only request it, according to users wishes. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: