Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.


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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group