On Wed, 2005-04-20 at 15:59 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
