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?
> We should not change to a less-safe default behavior when there is no
> need to.
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
ergonomical "fast" postmaster shutdown would send some message before
disconnecting all clients as well, but the fact that is does forcibly
disconnect seems required to me.
> > There should be an option to put the server log somewhere, either a file
> > or maybe a pipe, e.g.,
> > pg_ctl -l logfile
> > pg_ctl -P 'magic-log-rotator -x -y -z'
>
> Or we could just switch over to syslog as the standard log
> destination...
Not as long as all the good stuff goes to stderr.
> Perhaps the postmaster should have a '-u userid' option and do a
> setuid() call ... though I don't know whether this will be materially
> more portable than invoking su from a script.
Given that we do have pg_ctl, we can probably avoid a lot of headaches by
avoiding the setuid() business. There's no good solution for initdb in
that area anyway.
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?
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
