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

Fri, 26 Nov 1999 11:12:57 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
None
> 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

Thu, 25 Nov 1999 23:39:51 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: your mail
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
> 
> ************

Fri, 26 Nov 1999 13:55:13 +0700
Chairudin Sentosa Harjo <chai@prima.net.id>
Re: pg_ctl
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> 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.

How will pg_ctl know what to start --- where do the database directory,
port number, and path (to locate the postmaster executable) come from?

> Options for postmaster should be placed in
> $PGDATA/postmaster.conf.

Port number could reasonably be kept there, but I'm less sure about
path, and for sure there must be another way for pg_ctl to find PGDATA
in the first place...

> 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().

Security issues may be a factor here.  Do you want just anyone anywhere
on the net to be able to extract the postmaster status?  If not, how
shall we restrict it?

			regards, tom lane

Fri, 26 Nov 1999 10:38:06 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_ctl
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

Fri, 26 Nov 1999 11:04:10 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re:
> 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


Sat, 27 Nov 1999 11:05:31 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re:
From: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: pg_ctl
Date: Fri, 26 Nov 1999 10:38:06 -0500

> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > 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.
> 
> How will pg_ctl know what to start --- where do the database directory,
> port number, and path (to locate the postmaster executable) come from?

Very good question. What I'm thinking now is:

the database directory:
	1) $PGDATA (as an environmnet variable)
	2) hard coded in the pg_ctl script

the path to postmaster:
	1) in the command search path
	2) hard coded in the pg_ctl script
	3) assume that postmaster lives in the same directory where pg_ctl
	   has been put

> > 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().
> 
> Security issues may be a factor here.  Do you want just anyone anywhere
> on the net to be able to extract the postmaster status?  If not, how
> shall we restrict it?

I think a resonable restriction would be let anyone on the same
machine that postmaster is running could issue the protocol.

Another idea might be using our host based authentication. What about
having a "virtual database" used only for the status request protocol?
For example, with below setting, any authenticated user on the net
192.168.0.0 could send the protocol. "statusdb" indicates that backend
should treat it in the special way.

host  statusdb   192.168.0.0   255.255.255.0     crypt
--
Tatsuo Ishii


Sat, 27 Nov 1999 11:08:51 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: pg_ctl
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
> 
> 
> ************

Fri, 26 Nov 1999 21:31:30 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] Re: pg_ctl
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> Security issues may be a factor here.  Do you want just anyone anywhere
>> on the net to be able to extract the postmaster status?  If not, how
>> shall we restrict it?

> I think a resonable restriction would be let anyone on the same
> machine that postmaster is running could issue the protocol.

Grumble.  That's both too restrictive and not restrictive enough.
In an intranet-LAN kind of situation, you'd like to be able to check
the Postgres status without having to log into the specific machine
that's running the postmaster; while if the postmaster is running on
a large multiuser system, the very last thing that you want to do is
grant access to everyone else on the system.

> Another idea might be using our host based authentication. What about
> having a "virtual database" used only for the status request protocol?

That could be workable.  But I think I may have a better idea.

This morning after I sent my previous comments, I was thinking that the
really right way to do it would be to make the status info be a "virtual
table": you log into Postgres in the normal way, and issue a query
against some special table name, and if you've got the required access
rights then you get an answer.  The postgres superuser would always get
an answer, of course, and could grant/deny permissions to other users.

See, the advantage of doing it that way is that we build on top of the
existing Postgres access control and permission mechanisms, instead of
inventing a new set of mechanisms on the spur of the moment.  Compare
the Linux "/proc filesystem" for accessing system and process status
information --- /proc isn't a normal filesystem in any sense of the
word, but by making it look like one, the Linux folk managed to reuse
a lot of existing, well-tested lookup and permission-check mechanisms.

Offhand I don't see any reason to think that making system status look
like one or more virtual tables would be much harder to implement than
making it available via special-purpose postmaster protocols.  It seems
worth looking into, anyway.

If it doesn't work, then your idea is definitely the next thing to try:
recycle the pg_hba mechanisms to control access to a postmaster status
protocol.

			regards, tom lane

Fri, 26 Nov 1999 23:59:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_ctl 
> > I think a resonable restriction would be let anyone on the same
> > machine that postmaster is running could issue the protocol.
> 
> Grumble.  That's both too restrictive and not restrictive enough.
> In an intranet-LAN kind of situation, you'd like to be able to check
> the Postgres status without having to log into the specific machine
> that's running the postmaster; while if the postmaster is running on
> a large multiuser system, the very last thing that you want to do is
> grant access to everyone else on the system.

Ok, let's regard the functionality to report the status of postmaster
and/or backends be separate from pg_ctl.

> > Another idea might be using our host based authentication. What about
> > having a "virtual database" used only for the status request protocol?
> 
> That could be workable.  But I think I may have a better idea.
> 
> This morning after I sent my previous comments, I was thinking that the
> really right way to do it would be to make the status info be a "virtual
> table": you log into Postgres in the normal way, and issue a query
> against some special table name, and if you've got the required access
> rights then you get an answer.  The postgres superuser would always get
> an answer, of course, and could grant/deny permissions to other users.

Oracle already has the concept of "virtual table" and I like the idea
too.

> Offhand I don't see any reason to think that making system status look
> like one or more virtual tables would be much harder to implement than
> making it available via special-purpose postmaster protocols.  It seems
> worth looking into, anyway.

Tom, I remember you are going to enhance the function manager to allow
functions to return set of rows. If this is possible, it should be
very easy to implement the virtual tables.  Is that what is in your
mind?
--
Tatsuo Ishii


Sat, 27 Nov 1999 15:35:28 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: pg_ctl 
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> Offhand I don't see any reason to think that making system status look
>> like one or more virtual tables would be much harder to implement than
>> making it available via special-purpose postmaster protocols.  It seems
>> worth looking into, anyway.

> Tom, I remember you are going to enhance the function manager to allow
> functions to return set of rows.

Moi?  I don't recall saying any such thing.  Jan sounded like he had
some ideas about how to do it, but my ambitions for fmgr don't go
further than cleaning up NULL handling and fixing its portability
problems.  I have too many other things to do...

> If this is possible, it should be very easy to implement the virtual
> tables.

It would indeed provide a nice way of defining virtual tables --- just
make a function that returns the current table contents on-demand.

			regards, tom lane

Sat, 27 Nov 1999 12:10:12 -0500
Tom Lane <tgl@sss.pgh.pa.us>
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
> >
> >
> > ************
> 
> ************

Sun, 28 Nov 1999 15:02:57 -0500
Tim Holloway <mtsinc@southeast.net>
Re: [HACKERS] Re: pg_ctl
> > 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

Mon, 29 Nov 1999 00:20:13 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Re:
> 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


Mon, 29 Nov 1999 14:45:47 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re:
> > Tom, I remember you are going to enhance the function manager to allow
> > functions to return set of rows.
> 
> Moi?  I don't recall saying any such thing.  Jan sounded like he had
> some ideas about how to do it, but my ambitions for fmgr don't go
> further than cleaning up NULL handling and fixing its portability
> problems.  I have too many other things to do...

Sorry for the confusion.

> > If this is possible, it should be very easy to implement the virtual
> > tables.
> 
> It would indeed provide a nice way of defining virtual tables --- just
> make a function that returns the current table contents on-demand.

Anyway, it seems you already have an idea how to implement virtual
tables without modifying the fmgr. Can you tell me about that?
--
Tatsuo Ishii


Tue, 30 Nov 1999 10:21:22 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: pg_ctl 
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> It would indeed provide a nice way of defining virtual tables --- just
>> make a function that returns the current table contents on-demand.

> Anyway, it seems you already have an idea how to implement virtual
> tables without modifying the fmgr. Can you tell me about that?

No, I don't have any ideas --- I was just agreeing that it'd be a nice
thing if we could do it.

I am planning to add a "hook" field into the fmgr interface to allow
dealing with function results that can't be returned as a single Datum
(see previous discussions on hackers list).  But I'm not going to try
to write any code that makes use of that hook, at least not for 7.0.

			regards, tom lane

Mon, 29 Nov 1999 23:03:33 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: pg_ctl 