Re: A note about SIGTERM illusion and reality

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: A note about SIGTERM illusion and reality
Date: 2008-01-12 20:28:32
Message-ID: 21580.1200169712@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> After digging in the man page for init(8) on a couple of machines,
> I realized that the SIGTERM-then-SIGKILL behavior only applies to
> processes that are launched directly by init.

Actually, after further experimentation, it seems this is very
platform-dependent.

Current Linux (tested on Fedora 8) actually does behave in the way
our code expects, ie, every process gets a SIGTERM. The default
SIGTERM-to-SIGKILL delay is only 5 seconds, which is likely not enough
for a checkpoint in a busy database, but at least we tried :-(.

Mac OS X seems to issue everything SIGQUIT, instead of SIGTERM.
I didn't experiment to see how much grace period there might be.

No idea about other BSDen, though OS X's behavior might be typical.

HPUX seems to go straight to SIGKILL.

So the bottom line is that the best bet is to rely on an initscript's
stop command to issue "pg_ctl stop -m fast", which will give us enough
time to perform a clean shutdown. The other behavior is only of
interest for databases that aren't controlled by an initscript known
to the system. But there does seem to be some value in our designed
response to SIGTERM, on at least one popular platform, so I no longer
feel a need to rethink that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-12 20:39:29 Re: getting out boolean value from PQgetValue function
Previous Message Simon Riggs 2008-01-12 20:25:10 Re: Transaction Snapshot Cloning