Re: Problem with PITR recovery
От | Simon Riggs |
---|---|
Тема | Re: Problem with PITR recovery |
Дата | |
Msg-id | 1114032128.16721.2310.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Problem with PITR recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, 2005-04-20 at 15:59 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > Treating shutdown checkpoint markers as xlog switches is possible but > > gives problems since archive_command is a SUSET variable. On replay we > > wouldn't necessarily know whether a shutdown checkpoint was treated as > > an xlog switch when it was written, so we'd need to attempt to switch > > and look beyond the checkpoint marker, just in case. That makes me > > uncomfortable. > > [ Forgot to respond to this part... ] > > I think the only safe way to handle that would be to define a shutdown > checkpoint record as being effectively an end-of-file record ALWAYS, > whether archiving or not. This would be rather a problem for initdb, > which would go through a new XLOG segment for each of its multiple > calls to a standalone backend --- on the other hand, it's not real > clear why we couldn't fold initdb down to one bootstrap run and one > plain standalone backend run, which'd cut that problem down to the > point of tolerability. > > However, this still begs the question of why we are bothering. Thats a big question :-) > I disagree with the goal in this particular case anyhow: I do not > think it's necessary, safe, nor sane for a shutdown to try to archive > the last XLOG segment. Even if we fixed the xlog mechanism to end the > file there, I really have a problem with the idea that the archiver > should try to start a fresh archiving cycle at shutdown. Right now, I'm happy to leave that part anyhow... Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: