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
