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.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
