> 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
