Re: Archiver behavior at shutdown

On Thu, 2007-12-27 at 15:29 -0500, Tom Lane wrote:

> As of CVS HEAD, the behavior after the postmaster receives a shutdown
> request and has seen its last regular-backend child die is:

...based upon limitations of the existing system. We have been
SIGQUIT'ing the archiver, and there is a comment there to say how
important it is that we *do not* try to finish processing before we
quit. If you think that comment is wrong, thats OK by me: I can't recall
the reasoning there, or even if it was my own.

> ISTM the postmaster should leave the archiver alone at the
> PM_WAIT_BACKENDS -> PM_SHUTDOWN transition, and instead send it
> a WAKEN signal (SIGUSR1) when it sees normal exit of the bgwriter.
> That will afford an opportunity to archive anything that was pushed
> out during the shutdown checkpoint. A possibly better alternative,
> since the archiver isn't using SIGUSR2, is to send SIGUSR2 which
> would be defined as "archive what you can and then quit". (In that
> case, the !PostmasterIsAlive exit would be taken only in the event
> of a true postmaster crash, which is improbable.)

Sounds good.

> Another case that needs some revisiting is the archiver's response
> to SIGTERM, which is currently SIG_IGN. Since the postmaster will never
> send it SIGTERM, we should assume that receipt of SIGTERM means that
> init is telling us we have N seconds left before system shutdown.
> Is it a good idea to continue archiving in that situation? I doubt it
> --- it seems like we are just asking to get SIGKILL'd partway through a
> copy step. I suggest that the response to SIGTERM ought to be to finish
> out the current copy operation (if possible) but then quit without
> initiating any new ones.

Not sure about that. If there are outstanding files to archive, then it
probably is important to try to archive them. Mostly this won't be the
case, but if this was, for example a simple switchover between a primary
and a warm standby then it might result in data loss.

If you see problems with archive_commands that don't correctly reset
themselves after an error then we should document how to, rather than
just *try* to avoid it.

> And while I'm griping: I see that the pgstats process is SIGQUIT'ed at
> the entry to PM_SHUTDOWN state, same as the archiver. This likewise
> seems out of step with current reality, since the bgwriter now sends
> messages to the stats collector. This step needs to be moved to after
> bgwriter termination, too.

Sounds good.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com