Thread: pg_ctl wish list

pg_ctl wish list

From
Peter Eisentraut
Date:
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/



Re: pg_ctl wish list

From
Tom Lane
Date:
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


Re: pg_ctl wish list

From
Peter Eisentraut
Date:
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/



command-line option for logfile

From
Fred Yankowski
Date:
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


Re: pg_ctl wish list

From
Lamar Owen
Date:
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


Re: pg_ctl wish list

From
Peter Eisentraut
Date:
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/