On Fri, 26 Nov 1999, Tatsuo Ishii wrote:
> >If so, feel free to get the startup script
> > from the RedHat RPM set and cannibalize. This pg_ctl command is going to
> > greatly simplify startup scripts.
>
> Thanks. I know that the script is very convenient since I've been
> using the script for a while:-) This is one of the reason why I start
> to implemnt pg_ctl.
The script can become spoiling -- it's biggest problem is the need to run it as
root.
Ok, just a few suggestions:
1.) Allow either environment variables or command line switches to specify
PGDATA, PGLIB, postmaster location, port#, etc.
2.) Fallback to builtin defaults if no envvars or switches specified.
3.) Allow a mix of envvars and switches.
The locations needed:
PGDATA
PGLIB
PATH_TO_POSTMASTER
PGPORT
PATH_TO_PID (could need to be /var/run/pgsql for FHS compliance)
For the PID files, maybe use a format of postmaster.PGPORT (ie,
postmaster.5432). The PID files content, of course, needs to just be the
process identifier in ASCII followed by newline.
Also, options for logging could be passed -- maybe provide a switch to pass
options on to postmaster? This may need to wait for subsequent versions --
getting basic functionality first is a good idea.
It would be nice if a status report from postmaster could include the
envvars it was invoked with, the command line invoked with, and the other
things you already mentioned. (subject to security policy, of course).
For subsquent versions (not to complicate an initial version), being able to
run any version backend using the appropriate version libraries would be nice.
This would involve only one more option -- PATH_TO_POSTGRES. This way, I can
fire up an old postmaster (using an old backend) to dump a database, stop it,
and fire up a new postmaster (and backend) to restore.
I like this command.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
> --
> Tatsuo Ishii
>
>
> ************
