> 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
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
