Re: Clean shutdown and warm standby - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Clean shutdown and warm standby
Date
Msg-id 1243547234.24860.685.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Clean shutdown and warm standby  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Clean shutdown and warm standby
List pgsql-hackers
On Thu, 2009-05-28 at 19:58 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-05-28 at 18:02 +0300, Heikki Linnakangas wrote:
> > 
> >> postmaster never sends SIGTERM to pgarch, and postmaster is still alive.
> > 
> > Then we have a regression, since we changed the code to make sure the
> > archiver did shutdown even if there was a backlog.
> 
> The commit message of the commit that introduced the check for SIGTERM says:
> 
> "
> Also, modify the archiver process to notice SIGTERM and refuse to issue any
> more archive commands if it gets it.  The postmaster doesn't ever send it
> SIGTERM; we assume that any such signal came from init and is a notice of
> impending whole-system shutdown.  In this situation it seems imprudent 
> to try
> to start new archive commands --- if they aren't extremely quick they're
> likely to get SIGKILL'd by init.
> "

Sounds great, but what does that mean exactly?

The same commit message also says:

"The new behavior is that the archiver is allowed to run unmolested
until the bgwriter has exited; then it is sent SIGUSR2 to tell it to do
a final archiving cycle and quit."

Thus there is no guarantee that this is sufficient to have archived all
the files you would like to archive. The patch does not provide a clean
shutdown in all cases and since you don't know what state its in, you
are still forced to take external action to be safe, exactly as you do
already. 

If I didn't already say, I came up with exactly the same solution 2
years ago and then later explained it didn't work in all cases. I'm
saying the same thing again here now.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Next
From: Josh Berkus
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type