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

Re: How to shoot yourself in the foot: kill -9 postmaster

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Date: 2001-03-06 02:45:08
Message-ID: 3AA44F34.C8BE69D1@wgcr.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> However, with an explicit kill level that doesn't happen: you get one
> signal of the specified value, no more.  Possibly it would be better for
> the init script to send SIGINT (forcibly disconnect clients) instead of
> SIGTERM, however.  So I'm now leaning to "killproc postmaster -INT".

Ok, since I can't seem to count on killproc's exact behavior, istm that
I can:
killproc postmaster -INT
wait some number of seconds
if postmaster still up
   killproc postmaster -TERM
wait some number of seconds
if postmaster STILL up
   killproc postmaster  #and let the grim reaper do its dirty work.

After all, the system shutdown is relying on this script to properly and
thoroughly shut things down, or it WILL do the 'kill -9
pid-of-postmaster' for you.

Now, what's a good delay here?  Or is there a better metric that a
simple delay?  After all, I want to avoid the kill -9 unless we have an
emergency hard lock situation -- what's a good indicator of the backend
fleet of processes actually _doing_ something?  Or should I key on an
indicator of processor speed (Linux does provide a nice bogus metric
known as BogoMIPS for such a purpose)?  The last thing I want to do is
wait too long on some platforms and not long enough on others.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-03-06 02:53:05
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Previous:From: Tom LaneDate: 2001-03-06 02:40:41
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster

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