Skip site navigation (1) Skip section navigation (2)

Re: Clean shutdown and warm standby

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clean shutdown and warm standby
Date: 2009-05-28 21:47:14
Message-ID: 1243547234.24860.685.camel@ebony.2ndQuadrant (view raw, whole thread or download thread mbox)
Lists: 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

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 
 PostgreSQL Training, Services and Support

In response to


pgsql-hackers by date

Next:From: Joshua TolleyDate: 2009-05-28 22:07:39
Subject: Dtrace probes documentation
Previous:From: Bruce MomjianDate: 2009-05-28 21:46:22
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group