Re: pg_ctl wish list - Mailing list pgsql-hackers

Peter Eisentraut wrote:
> Tom Lane writes:
> > > "fast" shutdown should be the default, otherwise you may get surprises on
> > > system shutdown when users are still connected.

> > No, I don't think so.  During a system shutdown, init will deliver
> > SIGTERM to all the backends as well as the postmaster, so the backends
> > will die quite handily without the postmaster needing to give them any
> > additional push.
> During a system shutdown on my system, '{script} stop' will be called,
> which will (at present) send SIGTERM to the postmaster.  This will hang
> indefinitely at worst.  Assume that we don't configure it to wait
> (although we agreed on the opposite), and the global SIGTERM is sent out,
> is there some sort of ordering guarantee?

Hmmm. On RedHat, the appropriate runlevel is set -- 6 for reboot, 0 for
halt.  The SysV-init walks the rc.d subdir (rc6.d for reboot, rc0.d for
halt), finding a list of scripts.  The scripts are executed in ASCII
collation order, but, by convention, the scripts are symlinks to the
real scripts in /etc/rc.d/init.d.  Scripts starting with K are given a
parameter of 'stop', and ones starting with S are given a parameter of
'start'.  The K scripts (K85postgresql for example) are executed in
order, then the S scripts are executed.  The last two scripts to execute
are S00killall and S01reboot.

S00killall (symlink to ../init.d/killall) combs /var/lock/subsys for
services that were started but not stopped by their own initscript, and
invokes their script with the stop parameter if so.  This is a sanity
check.

S01reboot is a symlink to ../init.d/halt, and does the following:
1.)    Checks its invocation name.  If reboot, set up for reboot, if halt,
set up for halt.
2.)    Sends SIGTERM to all running processes, using /sbin/killall5, which
is a binary shipped with the SysVinit package to send a kill to all
processes.  The kills are likely sent in PID order, but a look at the
source to killall5 would be required to guarantee that.
3.)    halt -w to force a write to wtmp before /var is umounted.
4.)    Save mixer settings.
5.)    Turn off swap.
6.)    Unmount filesystems, using a sophisticated scheme that kills off any
remaining processes with open files on the filesystems to be unmounted
with SIGKILL.
7.)    Turn off RAID.
8.)    Unmount /proc.
9.)    Remount remaining filesystems (/ should be the only one) read-only.
10.)    Eval the command setup -- reboot for 'reboot', and halt for 'halt'.

But, in the context of the RedHat system, the postgresql initscript is
where the backend reaping should occur.  Recommendations as to algorithm
are welcome, as you correctly state that the script currently only
directly signals postmaster processes.

> Is it really less safe?  In my mind, the "fast" shutdown behaviour is
> appropriate for a system shutdown.  After all, the system shutdown doesn't
> wait for all users to log out either, it just says "See ya".  An

A system shutdown will forcibly disconnect all clients anyway, as NICs
are shutdown, etc. So a fast shutdown for system shutdown is entirely
appropriate, IMHO.

> > Or we could just switch over to syslog as the standard log
> > destination...
> Not as long as all the good stuff goes to stderr.
> I think the -w thing and the log output thing should be fixed before 7.1
> goes out the door.  Any comments on the particulars?

Where can elog() not be safely used?  I'll volunteer to grep and
replace, subbing appropriate elog parameters, but I'm not sure I can do
it in time for 7.1's release.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11