Horton

Thread

  1. Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-11-26T02:12:57Z

    Hi all,

Here is the first draft for the spec of postmaster starting/stopping
tool. I have named it as "pg_ctl."

o pg_ctl [-w] start

start up postmaster. If -w is specified, it will wait for the database
up and running.  Options for postmaster should be placed in
$PGDATA/postmaster.conf.

Note: pg_ctl assumes that postmaster writes its pid into
$PGDATA/postmaster.pid.

o pg_ctl [-w][-s|-f|-i] stop

stop postmaster. If -w is specified, it will wait for the database
shutting down.

Shutdown mode can be one of:

	-s: smart shutdown (default)
	-f: fast shutdown
	-i: immediate shutdown

o pg_ctl [-w][-s|-f|-i] restart

just stop and start postmaster.

o pg_ctl status

report the status of postmaster. It would be nice if it could report,
for example, the number of backends running (and their pids) etc. For
this purpose I propose followings:

(1) Add another protocol STATUS_REQUEST_CODE to libpq/pqcomm.h.

(2) Add code to process the protocol in
postmaster/postmaster.c:readStartupPacket().

Comments, suggestions are welcome.
--
Tatsuo Ishii

  2. Re: your mail

    Bruce Momjian <pgman@candle.pha.pa.us> — 1999-11-26T04:39:51Z

    > Hi all,
> 
> Here is the first draft for the spec of postmaster starting/stopping
> tool. I have named it as "pg_ctl."
> 
> o pg_ctl [-w] start
> 
> start up postmaster. If -w is specified, it will wait for the database
> up and running.  Options for postmaster should be placed in
> $PGDATA/postmaster.conf.
> 
> Note: pg_ctl assumes that postmaster writes its pid into
> $PGDATA/postmaster.pid.
> 
> o pg_ctl [-w][-s|-f|-i] stop

Looks good to me.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  3. Re: pg_ctl

    Chairudin Sentosa <chai@prima.net.id> — 1999-11-26T06:55:13Z

    How about adding pg_ctl [-w] restart?

It will automatically stop and start the database again.

Chai


Tatsuo Ishii wrote:
> 
> Hi all,
> 
> Here is the first draft for the spec of postmaster starting/stopping
> tool. I have named it as "pg_ctl."
> 
> o pg_ctl [-w] start
> 
> start up postmaster. If -w is specified, it will wait for the database
> up and running.  Options for postmaster should be placed in
> $PGDATA/postmaster.conf.
> 
> Note: pg_ctl assumes that postmaster writes its pid into
> $PGDATA/postmaster.pid.
> 
> o pg_ctl [-w][-s|-f|-i] stop
> 
> stop postmaster. If -w is specified, it will wait for the database
> shutting down.
> 
> Shutdown mode can be one of:
> 
>         -s: smart shutdown (default)
>         -f: fast shutdown
>         -i: immediate shutdown
> 
> o pg_ctl [-w][-s|-f|-i] restart
> 
> just stop and start postmaster.
> 
> o pg_ctl status
> 
> report the status of postmaster. It would be nice if it could report,
> for example, the number of backends running (and their pids) etc. For
> this purpose I propose followings:
> 
> (1) Add another protocol STATUS_REQUEST_CODE to libpq/pqcomm.h.
> 
> (2) Add code to process the protocol in
> postmaster/postmaster.c:readStartupPacket().
> 
> Comments, suggestions are welcome.
> --
> Tatsuo Ishii
> 
> ************

  4. Re:

    Lamar Owen <lamar.owen@wgcr.org> — 1999-11-26T16:04:10Z

    On Thu, 25 Nov 1999, Tatsuo Ishii wrote:
> Here is the first draft for the spec of postmaster starting/stopping
> tool. I have named it as "pg_ctl."

Tatsuo, are you implementing this?  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.

The RPM startup script is /etc/rc.d/init.d/postgresql, and can also get fetched
from my site at
http://www.ramifordistat.net/postgres/unpacked/non-beta/postgresql.init.6.5.3

If you're not implementing pg_ctl, I can take a stab at it.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  5. Re:

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-11-27T02:05:31Z

    > Tatsuo, are you implementing this?

Yes.

>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.
--
Tatsuo Ishii

  6. Re: [HACKERS] Re: pg_ctl

    Lamar Owen <lamar.owen@wgcr.org> — 1999-11-27T02:31:30Z

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

  7. Re: [HACKERS] Re: pg_ctl

    Tim Holloway <mtsinc@southeast.net> — 1999-11-28T20:02:57Z

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

  8. Re: [HACKERS] Re:

    Bruce Momjian <pgman@candle.pha.pa.us> — 1999-11-29T05:20:13Z

    > > Tatsuo, are you implementing this?
> 
> Yes.
> 
> >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.

Is there a reason it is called pg_ctl and not pg_control?  I find I
abbreviate control as ctrl, cntrl, cntl so I usually spell it out.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  9. Re: [HACKERS] Re:

    Tatsuo Ishii <t-ishii@sra.co.jp> — 1999-11-29T05:45:47Z

    > Is there a reason it is called pg_ctl and not pg_control?  I find I
> abbreviate control as ctrl, cntrl, cntl so I usually spell it out.

I just got the idea from "apachectl" or a famous system call "ioctl." 
However, if it's not natural for English speakers, I'm glad to change
it to more appropriate one.
--
Tatsuo Ishii