Thread: pg_ctl wish list
To alleviate the need for a start up script somewhat we could perhaps fix up pg_ctl to serve that purpose better. -w should be the default, as has been suggested. "fast" shutdown should be the default, otherwise you may get surprises on system shutdown when users are still connected. 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' The current behaviour, start server in background and leave stdin/stdout on terminal, and no nohup, is just plain wrong. I think there should also be a reasonable defense against not using one of these options, but I'm not sure what that could be. Maybe something like picking a default file based on PGDATA. There should be an option to not print informational messages, so startup scripts can implement their own message systems without resorting to the draconian '>/dev/null 2>&1'. Some option that invokes 'su' with an appropriate user name. Not sure whether you can invoke 'su' portably. Finally, maybe a default PGDATA would be useful, although I'm not fond of it personally. Comments? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> To alleviate the need for a start up script somewhat we could perhaps fix
> up pg_ctl to serve that purpose better.
> -w should be the default, as has been suggested.
Agreed.
> "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. We should not change to a less-safe default behavior
when there is no need to.
> 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...
> The current behaviour, start server in background and leave stdin/stdout
> on terminal, and no nohup, is just plain wrong.
Agreed.
> Some option that invokes 'su' with an appropriate user name. Not sure
> whether you can invoke 'su' portably.
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.
regards, tom lane
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/
A command-line option for specifying the logfile would be very helpful on WIN32. When setting up PostgreSQL to run as an NT service, the only way I can see to redirect stdout/stderr to a file is to invoke postmaster via a wrapper sh/bash process. I suspect that this wrapper process would have to hang around as long as postmaster is running, although it might be possible to do an exec to overlay it. It would be nice to avoid this wrapper process. On Mon, Feb 05, 2001 at 06:01:10PM +0100, Peter Eisentraut wrote: > > > 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. -- Fred Yankowski fred@OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA
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
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > > To alleviate the need for a start up script somewhat we could perhaps fix > > up pg_ctl to serve that purpose better. > > > -w should be the default, as has been suggested. > > Agreed. But we need to make up a better way to wait for postmaster startup. The current 'psql -l' is no good, as we have discussed, but if this thing is going into system startup scripts mainstream now we can't have that kind of random behaviour. Actually, trying to connect is wrong-headed anyway. If the user has a peculiar setup to disallow connections from the local host (virtual host maybe), even if it is only a temporary misconfiguration, we should still be able to start up in good faith. How is "successfully started up" constrained anyway? Even if we had a way to check that, the postmaster could still choose to abort briefly after our check, e.g., during the backend reaping phase. Maybe waiting on startup isn't so important to worry about it. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/