Re: [HACKERS] Re: pg_ctl

From: Tim Holloway <mtsinc(at)southeast(dot)net>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: pg_ctl
Date: 1999-11-28 20:02:57
Message-ID: 38418A71.10CFDFE2@southeast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
> >
> >
> > ************
>
> ************

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-11-28 22:43:57 Re: [HACKERS] UNION not allowed in sub-selects?
Previous Message Oliver Elphick 1999-11-28 19:50:55 UNION not allowed in sub-selects?