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

> 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.

In remembering how other databases handle it, I think you should use
pg_ctl to shut it down.  You need to enable wait mode, not sure if that
is the default or not.  That will wait for it to shut down before
continuing.  I realize a hung shutdown would stop the kernel from
shutting down.  You could put a sleep 100 in there and call a trap on a
timeout.

Here is some shell code:
TIME=60    pg_ctl -w stop &BG="$!"; export BG
(sleep "$TIME"; kill "$BG" ) &BG2="$!"; export BG2
wait "$BG"if ! kill -0 "$BG2"else    kill "$BG2"fi


This will try a pg_ctl shutdown for 60 seconds, then kill pg_ctl.  You
would then need a kill of you own.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026