Re: [HACKERS] Re: pg_ctl

I have a logging subsystem running - just waiting for some aid on an OS-related
bug - but it supports processing an arbitrarily complex options file (both log and 
non-log options) and display/logging of the environment options and other
parameters of interest.
  regards,
    Tim Holloway

Lamar Owen wrote:
> 
> 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
> >
> >
> > ************
> 
> ************