Thread: ...
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
> 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, Pennsylvania19026
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 > > ************
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
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
> 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
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 path2) hard coded in the pg_ctl script3) assume that postmaster lives inthe 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
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 > > > ************
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
> > 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
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
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
> >
> >
> > ************
>
> ************
> > 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, Pennsylvania19026
> 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
> > 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
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