Thread: pg_ctl idempotent option
Here is a patch to add an option -I/--idempotent to pg_ctl, the result of which is that pg_ctl doesn't error on start or stop if the server is already running or already stopped. The previous discussion was at <http://www.postgresql.org/message-id/1253165415.18853.32.camel@vanquo.pezone.net>.
Attachment
Peter Eisentraut <peter_e@gmx.net> writes:
> Here is a patch to add an option -I/--idempotent to pg_ctl, the result
> of which is that pg_ctl doesn't error on start or stop if the server is
> already running or already stopped.
Idempotent is a ten-dollar word. Can we find something that average
people wouldn't need to consult a dictionary to understand?
Also, should the option affect *only* the result code as you have it,
or should it also change the printed messages to reflect that the
case is considered expected?
Also it appears to me that the hunk at lines 812ff is changing the
default behavior, which is not what the patch is advertised to do.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > > of which is that pg_ctl doesn't error on start or stop if the server is > > already running or already stopped. > > Idempotent is a ten-dollar word. Can we find something that average > people wouldn't need to consult a dictionary to understand? --no-error perhaps? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> Here is a patch to add an option -I/--idempotent to pg_ctl, the result
>>> of which is that pg_ctl doesn't error on start or stop if the server is
>>> already running or already stopped.
>> Idempotent is a ten-dollar word. Can we find something that average
>> people wouldn't need to consult a dictionary to understand?
> --no-error perhaps?
Meh, that's probably going too far in the direction of imprecision.
The point of this patch is that only very specific errors are
suppressed.
I don't have a better idea though. It'd be easier if there were
separate switches for the two cases, then you could call them
--ok-if-running and --ok-if-stopped. But that's not very workable,
if only because both would want the same single-letter abbreviation.
regards, tom lane
On 14 January 2013 15:29, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
--
Thom
Tom Lane wrote:--no-error perhaps?
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Here is a patch to add an option -I/--idempotent to pg_ctl, the result
> > of which is that pg_ctl doesn't error on start or stop if the server is
> > already running or already stopped.
>
> Idempotent is a ten-dollar word. Can we find something that average
> people wouldn't need to consult a dictionary to understand?
Couldn't that be misconstrued as to suppress any type of error?
I personally can't think of something terse enough to put into a descriptive long-word option that would adequately describe the change in behaviour it provides.
--suppress-error-when-target-status-already-present ... bit too wordy. ;)
Thom
2013-01-14 16:22 keltezéssel, Tom Lane írta: > Peter Eisentraut <peter_e@gmx.net> writes: >> Here is a patch to add an option -I/--idempotent to pg_ctl, the result >> of which is that pg_ctl doesn't error on start or stop if the server is >> already running or already stopped. > Idempotent is a ten-dollar word. Can we find something that average > people wouldn't need to consult a dictionary to understand? --do-nothing-if-same-state? > > Also, should the option affect *only* the result code as you have it, > or should it also change the printed messages to reflect that the > case is considered expected? > > Also it appears to me that the hunk at lines 812ff is changing the > default behavior, which is not what the patch is advertised to do. > > regards, tom lane > > -- ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
2013/1/14 Tom Lane <tgl@sss.pgh.pa.us>: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: >> Tom Lane wrote: >>> Peter Eisentraut <peter_e@gmx.net> writes: >>>> Here is a patch to add an option -I/--idempotent to pg_ctl, the result >>>> of which is that pg_ctl doesn't error on start or stop if the server is >>>> already running or already stopped. > >>> Idempotent is a ten-dollar word. Can we find something that average >>> people wouldn't need to consult a dictionary to understand? > >> --no-error perhaps? > > Meh, that's probably going too far in the direction of imprecision. > The point of this patch is that only very specific errors are > suppressed. > > I don't have a better idea though. It'd be easier if there were > separate switches for the two cases, then you could call them > --ok-if-running and --ok-if-stopped. But that's not very workable, > if only because both would want the same single-letter abbreviation. --ignore-status --ignore-status-start --ignore-status-stop ? Regards -- Dickson S. Guedes mail/xmpp: guedes@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br
<div dir="ltr">On Mon, Jan 14, 2013 at 4:22 PM, Tom Lane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><div class="gmail_extra"><div class="gmail_quote"><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Peter Eisentraut <<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>> writes:<br /> >Here is a patch to add an option -I/--idempotent to pg_ctl, the result<br /> > of which is that pg_ctl doesn't erroron start or stop if the server is<br /> > already running or already stopped.<br /><br /> Idempotent is a ten-dollarword. Can we find something that average<br /> people wouldn't need to consult a dictionary to understand?<br/></blockquote></div><br /></div><div class="gmail_extra">I disagree that we should dumb things down when theword means exactly what we want and based on the rest of this thread is the only word or word cluster that carries thedesired meaning.<br /><br /></div>I vote to keep --idempotent.<br /><div class="gmail_extra"><br /></div><div class="gmail_extra">Vik<br/></div></div>
Vik Reykja escribió: > On Mon, Jan 14, 2013 at 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > Peter Eisentraut <peter_e@gmx.net> writes: > > > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > > > of which is that pg_ctl doesn't error on start or stop if the server is > > > already running or already stopped. > > > > Idempotent is a ten-dollar word. Can we find something that average > > people wouldn't need to consult a dictionary to understand? > > > > I disagree that we should dumb things down when the word means exactly what > we want and based on the rest of this thread is the only word or word > cluster that carries the desired meaning. > > I vote to keep --idempotent. Yeah, after seeing the alternatives, I agree that it seems okay, particularly given that the --help output explains the behavior in dime-a-dozen words. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Vik Reykja escribi�:
>> On Mon, Jan 14, 2013 at 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Idempotent is a ten-dollar word. Can we find something that average
>>> people wouldn't need to consult a dictionary to understand?
>> I disagree that we should dumb things down when the word means exactly what
>> we want and based on the rest of this thread is the only word or word
>> cluster that carries the desired meaning.
I'm not quite convinced that it means *exactly* what we want. The
dictionary definition, according to my laptop's dictionary, is "denoting
an element of a set that is unchanged in value when multiplied or
otherwise operated on by itself". I'm well aware that computer people
often use it to mean "an operation that doesn't change the system state
if the state is already what's wanted", but I think that's probably an
abuse of the mathematical usage. And in any case, I'm not sure that
non-hackers would immediately recognize the term, nor be enlightened by
their dictionaries. But ...
> Yeah, after seeing the alternatives, I agree that it seems okay,
... I was only asking if we *could* find a better choice. Seems we
can't, so let's stick with this.
regards, tom lane
On 1/14/13 10:22 AM, Tom Lane wrote: > Also it appears to me that the hunk at lines 812ff is changing the > default behavior, which is not what the patch is advertised to do. True, I had forgotten to mention that. Since it's already the behavior for start, another option would be to just make it the default for stop as well and forget about the extra options. I'm not sure whether there is a big use case for getting an error code on stop if the server is already stopped.
On 1/14/13 10:22 AM, Tom Lane wrote: > Idempotent is a ten-dollar word. Can we find something that average > people wouldn't need to consult a dictionary to understand? My suggestion in the original thread was --oknodo, but people didn't like that either.
Peter Eisentraut <peter_e@gmx.net> writes:
> On 1/14/13 10:22 AM, Tom Lane wrote:
>> Also it appears to me that the hunk at lines 812ff is changing the
>> default behavior, which is not what the patch is advertised to do.
> True, I had forgotten to mention that.
> Since it's already the behavior for start, another option would be to
> just make it the default for stop as well and forget about the extra
> options. I'm not sure whether there is a big use case for getting an
> error code on stop if the server is already stopped.
Actually, I seem to recall having had to hack Red Hat's initscript
because the LSB standard requires that stopping a not-running server
*not* be an error. So +1 for forgetting about the option entirely
and just making it idempotent all the time.
regards, tom lane
On Tue, Jan 15, 2013 at 10:25:23AM -0500, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Vik Reykja escribi�: > >> On Mon, Jan 14, 2013 at 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> Idempotent is a ten-dollar word. Can we find something that average > >>> people wouldn't need to consult a dictionary to understand? > > >> I disagree that we should dumb things down when the word means exactly what > >> we want and based on the rest of this thread is the only word or word > >> cluster that carries the desired meaning. > > I'm not quite convinced that it means *exactly* what we want. The > dictionary definition, according to my laptop's dictionary, is "denoting > an element of a set that is unchanged in value when multiplied or > otherwise operated on by itself". I'm well aware that computer people > often use it to mean "an operation that doesn't change the system state > if the state is already what's wanted", but I think that's probably an > abuse of the mathematical usage. And in any case, I'm not sure that > non-hackers would immediately recognize the term, nor be enlightened by > their dictionaries. But ... I have heard idempotent used several times by our folks, and I didn't know what it meant either. I figured it was a "strong item". ;-) I just looked it up. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Tue, Jan 15, 2013 at 10:55:41AM -0500, Peter Eisentraut wrote: > On 1/14/13 10:22 AM, Tom Lane wrote: > > Idempotent is a ten-dollar word. Can we find something that average > > people wouldn't need to consult a dictionary to understand? > > My suggestion in the original thread was --oknodo, but people didn't > like that either. That's Japanese for idempotent. ;-) LOL -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
2013-01-15 20:28 keltezéssel, Bruce Momjian írta: > On Tue, Jan 15, 2013 at 10:25:23AM -0500, Tom Lane wrote: >> Alvaro Herrera <alvherre@2ndquadrant.com> writes: >>> Vik Reykja escribi�: >>>> On Mon, Jan 14, 2013 at 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>>> Idempotent is a ten-dollar word. Can we find something that average >>>>> people wouldn't need to consult a dictionary to understand? >>>> I disagree that we should dumb things down when the word means exactly what >>>> we want and based on the rest of this thread is the only word or word >>>> cluster that carries the desired meaning. >> I'm not quite convinced that it means *exactly* what we want. The >> dictionary definition, according to my laptop's dictionary, is "denoting >> an element of a set that is unchanged in value when multiplied or >> otherwise operated on by itself". I'm well aware that computer people >> often use it to mean "an operation that doesn't change the system state >> if the state is already what's wanted", but I think that's probably an >> abuse of the mathematical usage. And in any case, I'm not sure that >> non-hackers would immediately recognize the term, nor be enlightened by >> their dictionaries. But ... > I have heard idempotent used several times by our folks, and I didn't > know what it meant either. I figured it was a "strong item". ;-) I > just looked it up. The math term used in Hungarian for idempotent is mirror translated to "leave it in place". The term also has a slang usage for beating somebody up. ;-) -- ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
On 01/15/2013 07:55 AM, Peter Eisentraut wrote: > On 1/14/13 10:22 AM, Tom Lane wrote: >> Idempotent is a ten-dollar word. Can we find something that average >> people wouldn't need to consult a dictionary to understand? > > My suggestion in the original thread was --oknodo, but people didn't > like that either. I'm pretty sure that Oknodo is an island in the Pacific. ;-) I don't have a better idea for a name, though. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, Jan 16, 2013 at 4:29 AM, Bruce Momjian <bruce@momjian.us> wrote:
--
Michael Paquier
http://michael.otacoo.com
That's Japanese for idempotent. ;-) LOL
+1.
Michael Paquier
http://michael.otacoo.com
On Tue, Jan 15, 2013 at 11:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> On 1/14/13 10:22 AM, Tom Lane wrote: >>> Also it appears to me that the hunk at lines 812ff is changing the >>> default behavior, which is not what the patch is advertised to do. > >> True, I had forgotten to mention that. > >> Since it's already the behavior for start, another option would be to >> just make it the default for stop as well and forget about the extra >> options. I'm not sure whether there is a big use case for getting an >> error code on stop if the server is already stopped. > > Actually, I seem to recall having had to hack Red Hat's initscript > because the LSB standard requires that stopping a not-running server > *not* be an error. So +1 for forgetting about the option entirely > and just making it idempotent all the time. +1 > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 18, 2013 at 8:48 PM, Phil Sorber <phil@omniti.com> wrote: > > +1 > Is there more work being done on this, or is the current patch ready to review?
On Tue, Jan 15, 2013 at 9:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On 1/14/13 10:22 AM, Tom Lane wrote:
>>> Also it appears to me that the hunk at lines 812ff is changing the
>>> default behavior, which is not what the patch is advertised to do.
>
>> True, I had forgotten to mention that.
>
>> Since it's already the behavior for start, another option would be to
>> just make it the default for stop as well and forget about the extra
>> options.
By default, (without idempotent option), if it finds the pid, it tries
to start one. If there is already one running, it exits with errorcode
1, otherwise it has already run the server.814 exitcode = start_postmaster();815 if (exitcode != 0)816
{817 write_stderr(_("%s: could not start server: exit code was %d\n"),818 progname,
exitcode);819 exit(1);820 }
What we can do under idempotent is to return with code 0 instead of
exit(1) above, thus not need the changes in the patch around line 812.
That will be more in-line with the description at
http://www.postgresql.org/message-id/1253165415.18853.32.camel@vanquo.pezone.net
> for example an exit
> code of 0 for an attempt to start a server which is already running
> or an attempt to stop a server which isn't running. (These are only
> two examples of differences between what is required of an LSB
> conforming init script and what pg_ctl does. Are we all in universal
> agreement to make such a change to pg_ctl?
anyway, +1 for making this as default option. Going that path, would
we be breaking backward compatibility? There might be scripts, (being
already used), which depend upon the current behaviour.
> I'm not sure whether there is a big use case for getting an
>> error code on stop if the server is already stopped.
>
> Actually, I seem to recall having had to hack Red Hat's initscript
> because the LSB standard requires that stopping a not-running server
> *not* be an error. So +1 for forgetting about the option entirely
> and just making it idempotent all the time.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
On Tue, Jan 22, 2013 at 06:03:28PM +0530, Ashutosh Bapat wrote:
> On Tue, Jan 15, 2013 at 9:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Peter Eisentraut <peter_e@gmx.net> writes:
> >> On 1/14/13 10:22 AM, Tom Lane wrote:
> >>> Also it appears to me that the hunk at lines 812ff is changing the
> >>> default behavior, which is not what the patch is advertised to do.
> >
> >> True, I had forgotten to mention that.
> >
> >> Since it's already the behavior for start, another option would be to
> >> just make it the default for stop as well and forget about the extra
> >> options.
>
> By default, (without idempotent option), if it finds the pid, it tries
> to start one. If there is already one running, it exits with errorcode
> 1, otherwise it has already run the server.
> 814 exitcode = start_postmaster();
> 815 if (exitcode != 0)
> 816 {
> 817 write_stderr(_("%s: could not start server: exit code was %d\n"),
> 818 progname, exitcode);
> 819 exit(1);
> 820 }
>
> What we can do under idempotent is to return with code 0 instead of
> exit(1) above, thus not need the changes in the patch around line 812.
> That will be more in-line with the description at
> http://www.postgresql.org/message-id/1253165415.18853.32.camel@vanquo.pezone.net
>
> > for example an exit
> > code of 0 for an attempt to start a server which is already running
> > or an attempt to stop a server which isn't running. (These are only
> > two examples of differences between what is required of an LSB
> > conforming init script and what pg_ctl does. Are we all in universal
> > agreement to make such a change to pg_ctl?
>
> anyway, +1 for making this as default option. Going that path, would
> we be breaking backward compatibility? There might be scripts, (being
> already used), which depend upon the current behaviour.
FYI, I have a pg_upgrade patch that relies on the old throw-an-error
behavior. Will there be a way to still throw an error if we make
idempotent the default?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
On 23.01.2013 20:56, Bruce Momjian wrote: > On Tue, Jan 22, 2013 at 06:03:28PM +0530, Ashutosh Bapat wrote: >> anyway, +1 for making this as default option. Going that path, would >> we be breaking backward compatibility? There might be scripts, (being >> already used), which depend upon the current behaviour. > > FYI, I have a pg_upgrade patch that relies on the old throw-an-error > behavior. Will there be a way to still throw an error if we make > idempotent the default? Could you check the status with "pg_ctl status" first, and throw an error if it's not what you expected? - Heikki
On Wed, Jan 23, 2013 at 09:00:25PM +0200, Heikki Linnakangas wrote: > On 23.01.2013 20:56, Bruce Momjian wrote: > >On Tue, Jan 22, 2013 at 06:03:28PM +0530, Ashutosh Bapat wrote: > >>anyway, +1 for making this as default option. Going that path, would > >>we be breaking backward compatibility? There might be scripts, (being > >>already used), which depend upon the current behaviour. > > > >FYI, I have a pg_upgrade patch that relies on the old throw-an-error > >behavior. Will there be a way to still throw an error if we make > >idempotent the default? > > Could you check the status with "pg_ctl status" first, and throw an > error if it's not what you expected? Well, this could still create a period of time where someone else starts the server between my status and my starting it. Do we really want that? And what if I want to start it with my special -o parameters, and I then can't tell if it was already running or it is using my parameters. I think an idempotent default is going to cause problems. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
I agree, answering the question, whether the particular attempt of starting a server succeeded or not, will need the current behaviour. Now, question is which of these behaviours should be default? Bruce, what if we make idempotent behaviour default and provide an option for current behaviour? On Thu, Jan 24, 2013 at 12:36 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Wed, Jan 23, 2013 at 09:00:25PM +0200, Heikki Linnakangas wrote: >> On 23.01.2013 20:56, Bruce Momjian wrote: >> >On Tue, Jan 22, 2013 at 06:03:28PM +0530, Ashutosh Bapat wrote: >> >>anyway, +1 for making this as default option. Going that path, would >> >>we be breaking backward compatibility? There might be scripts, (being >> >>already used), which depend upon the current behaviour. >> > >> >FYI, I have a pg_upgrade patch that relies on the old throw-an-error >> >behavior. Will there be a way to still throw an error if we make >> >idempotent the default? >> >> Could you check the status with "pg_ctl status" first, and throw an >> error if it's not what you expected? > > Well, this could still create a period of time where someone else starts > the server between my status and my starting it. Do we really want > that? And what if I want to start it with my special -o parameters, and > I then can't tell if it was already running or it is using my > parameters. I think an idempotent default is going to cause problems. > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company
On Thu, Jan 24, 2013 at 09:05:59AM +0530, Ashutosh Bapat wrote: > I agree, answering the question, whether the particular attempt of > starting a server succeeded or not, will need the current behaviour. > Now, question is which of these behaviours should be default? That would work. pg_upgrade knows the cluster version at that point and can use the proper flag. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
I am working on reviewing the patch. Patch apply without warning/error on master branch. My findings are as following i.e.
On Thu, Jan 24, 2013 at 6:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
1. Behavior change in pg_ctl return value i.e.
Server already running
a. Without Patch
inst asif$ ./bin/pg_ctl -D data_test/ -l data_test.log startpg_ctl: another server might be running; trying to start server anywayserver startinginst asif$ echo $?0
b. With Patch
inst_pg_ctl_idempotent_option asif$ ./bin/pg_ctl -D data_test/ -l data_test.log start
pg_ctl: another server might be running
inst_pg_ctl_idempotent_option asif$ echo $?
1
2. -w option seems not working for start as per documentation, it should return 0.
Starting already running server with -I -w option
inst_pg_ctl_idempotent_option asif$ ./bin/pg_ctl -D data_test/ -l data_test.log -I -w startpg_ctl: another server might be running; trying to start server anywaywaiting for server to start........pg_ctl: this data directory appears to be running a pre-existing postmasterstopped waitingpg_ctl: could not start serverExamine the log output.inst_pg_ctl_idempotent_option asif$ echo $?1
3. I believe postmaster (DAEMON="$prefix/bin/postmaster") is not going to accept "-I" option as mentioned in the patch i.e.
contrib/start-scripts/linuxsu - $PGUSER -c "$DAEMON -I -D '$PGDATA' &" >>$PGLOG 2>&
Rest of the patch changes looks good to me. Thanks.
Best Regards,
Asif Naeem
On Thu, Jan 24, 2013 at 09:05:59AM +0530, Ashutosh Bapat wrote:That would work. pg_upgrade knows the cluster version at that point and
> I agree, answering the question, whether the particular attempt of
> starting a server succeeded or not, will need the current behaviour.
> Now, question is which of these behaviours should be default?
can use the proper flag.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 14 January 2013 15:29, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Tom Lane wrote: >> Peter Eisentraut <peter_e@gmx.net> writes: >> > Here is a patch to add an option -I/--idempotent to pg_ctl, the result >> > of which is that pg_ctl doesn't error on start or stop if the server is >> > already running or already stopped. >> >> Idempotent is a ten-dollar word. Can we find something that average >> people wouldn't need to consult a dictionary to understand? > > --no-error perhaps? I think --force would be the accepted way to ensure something happens as specified Mind you, I'm not sure I see the value in throwing an error if the server is in the desired state already. Who actually wants that behaviour? Can't we just change the behaviour? Existing scripts would still work, since we are simply skipping an error. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Jan 28, 2013 at 03:40:08PM +0000, Simon Riggs wrote: > On 14 January 2013 15:29, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > Tom Lane wrote: > >> Peter Eisentraut <peter_e@gmx.net> writes: > >> > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > >> > of which is that pg_ctl doesn't error on start or stop if the server is > >> > already running or already stopped. > >> > >> Idempotent is a ten-dollar word. Can we find something that average > >> people wouldn't need to consult a dictionary to understand? > > > > --no-error perhaps? > > > I think --force would be the accepted way to ensure something happens > as specified > > > Mind you, I'm not sure I see the value in throwing an error if the > server is in the desired state already. Who actually wants that > behaviour? Can't we just change the behaviour? Existing scripts would > still work, since we are simply skipping an error. pg_upgrade uses that to find out of the server was already running or if we started it. This is to start the server to remove the postmaster.pid file. Also, no one has explained how not knowing if -o options were used was a safe. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Mon, Jan 28, 2013 at 09:29:35PM -0500, Bruce Momjian wrote: > On Mon, Jan 28, 2013 at 03:40:08PM +0000, Simon Riggs wrote: > > On 14 January 2013 15:29, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > > Tom Lane wrote: > > >> Peter Eisentraut <peter_e@gmx.net> writes: > > >> > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > > >> > of which is that pg_ctl doesn't error on start or stop if the server is > > >> > already running or already stopped. > > >> > > >> Idempotent is a ten-dollar word. Can we find something that average > > >> people wouldn't need to consult a dictionary to understand? > > > > > > --no-error perhaps? > > > > > > I think --force would be the accepted way to ensure something happens > > as specified > > > > > > Mind you, I'm not sure I see the value in throwing an error if the > > server is in the desired state already. Who actually wants that > > behaviour? Can't we just change the behaviour? Existing scripts would > > still work, since we are simply skipping an error. > > pg_upgrade uses that to find out of the server was already running or if > we started it. This is to start the server to remove the > postmaster.pid file. Also, no one has explained how not knowing if -o > options were used was a safe. OK, I had some time to think about this. Basically, we have three outcomes for pg_ctl start: server not running and pg_ctl start successserver start failedserver already running Can't we just assign different return values to these cases, e.g. 0, 1, 2? We already print output telling the user what happened. I don't think I like --force because it isn't clear if we are forcing the start to have done something, or forcing the server to be running. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
> OK, I had some time to think about this. Basically, we have three > outcomes for pg_ctl start: > > server not running and pg_ctl start success > server start failed > server already running > > Can't we just assign different return values to these cases, e.g. 0, 1, > 2? We already print output telling the user what happened. Not sure if that would work. Too many admin scripts only check for error output, and not what the error code was. FWIW, the Solaris/Opensolaris service scripts, as well as the RH service scripts (I think), already handle things this way. If you say: svcadm enable postgresql ... and postgres is already up, it just returns 0. So it's a common pattern. So, alternate suggestions to "idempotent": --isup --isrunning --ignorerunning However, I'm really beginnging to think that a switch isn't correct, and what we need to do is to have a different pg_ctl *command*, e.g.: pg_ctl -D . on or pg_ctl -D . enable > I don't think I like --force because it isn't clear if we are forcing > the start to have done something, or forcing the server to be running. Agfeed. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Tue, Jan 29, 2013 at 10:49 AM, Josh Berkus <josh@agliodbs.com> wrote:
Not sure if that would work. Too many admin scripts only check for
> OK, I had some time to think about this. Basically, we have three
> outcomes for pg_ctl start:
>
> server not running and pg_ctl start success
> server start failed
> server already running
>
> Can't we just assign different return values to these cases, e.g. 0, 1,
> 2? We already print output telling the user what happened.
error output, and not what the error code was.
FWIW, the Solaris/Opensolaris service scripts, as well as the RH service
scripts (I think), already handle things this way. If you say:
svcadm enable postgresql
... and postgres is already up, it just returns 0. So it's a common
pattern.
So, alternate suggestions to "idempotent":
--isup
--isrunning
--ignorerunning
However, I'm really beginnging to think that a switch isn't correct, and
what we need to do is to have a different pg_ctl *command*, e.g.:
pg_ctl -D . on
or
pg_ctl -D . enable
I doubt if that would help much. We will need to coin a new command for stop as well. A new pg_ctl command would confuse user as to what it should be using "on" or "start" in a given scenario. I think switch is better. Above switches won't look good with stop. We need some word/phrase which is good for both start and stop commands.
> I don't think I like --force because it isn't clear if we are forcingAgfeed.
> the start to have done something, or forcing the server to be running.--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
On Tue, Jan 29, 2013 at 04:19:15PM +1100, Josh Berkus wrote: > > > OK, I had some time to think about this. Basically, we have three > > outcomes for pg_ctl start: > > > > server not running and pg_ctl start success > > server start failed > > server already running > > > > Can't we just assign different return values to these cases, e.g. 0, 1, > > 2? We already print output telling the user what happened. > > Not sure if that would work. Too many admin scripts only check for > error output, and not what the error code was. > > FWIW, the Solaris/Opensolaris service scripts, as well as the RH service > scripts (I think), already handle things this way. If you say: > > svcadm enable postgresql > > ... and postgres is already up, it just returns 0. So it's a common > pattern. > > So, alternate suggestions to "idempotent": > > --isup > --isrunning > --ignorerunning > > However, I'm really beginnging to think that a switch isn't correct, and > what we need to do is to have a different pg_ctl *command*, e.g.: > > pg_ctl -D . on > or > pg_ctl -D . enable Yeah, that makes a lot of sense. > > I don't think I like --force because it isn't clear if we are forcing > > the start to have done something, or forcing the server to be running. Do we need this idempotent feature for "stop" too? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes: > pg_upgrade uses that to find out of the server was already running or if > we started it. This is to start the server to remove the > postmaster.pid file. Also, no one has explained how not knowing if -o > options were used was a safe. What happened to the plan for pg_upgrade to use a new standalone facility that also allows to run a normal psql in single-user mode? IIRC the only thing we didn't want out of that patch was to market the feature as an embedded mode of operations, because it's not, and some level of faith that it's not blocking any future development of a proper embedded mode. Baring that, using the feature for pg_upgrade makes so much sense that I'm left wondering why we're even still having the poor script trying to decipher so much situations that the postmaster itself has no problem dealing with. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 1/28/13 9:29 PM, Bruce Momjian wrote: > pg_upgrade uses that to find out of the server was already running or if > we started it. This is to start the server to remove the > postmaster.pid file. It's currently a bit missed up anyway. pg_ctl start is successful if the server is already started, but pg_ctl -w start fails. What pg_upgrade is doing doesn't sound particularly safe, for example when something is concurrently starting or stopping the server. > Also, no one has explained how not knowing if -o > options were used was a safe. Hmm, good point. But we already have this problem -- see above.
On Tue, Jan 29, 2013 at 04:34:50PM -0500, Peter Eisentraut wrote: > On 1/28/13 9:29 PM, Bruce Momjian wrote: > > pg_upgrade uses that to find out of the server was already running or if > > we started it. This is to start the server to remove the > > postmaster.pid file. > > It's currently a bit missed up anyway. pg_ctl start is successful if > the server is already started, but pg_ctl -w start fails. Yeah, that is odd: # pg_ctl startpg_ctl: another server might be running; trying to start server anywayserver starting# FATAL: lock file "postmaster.pid"already existsHINT: Is another postmaster (PID 14144) running in data directory "/u/pgsql/data"?# echo $?0#pg_ctl -w startpg_ctl: another server might be running; trying to start server anywaywaiting for server to start....FATAL: lock file "postmaster.pid" already existsHINT: Is another postmaster (PID 14144) running in data directory"/u/pgsql/data"?....pg_ctl: this data directory appears to be running a pre-existing postmaster stopped waitingpg_ctl:could not start serverExamine the log output.# echo $?1 It is because pg_ctl without -w doesn't want to see if the start was successful. Fortunately, pg_upgrade always uses -w. > What pg_upgrade is doing doesn't sound particularly safe, for example > when something is concurrently starting or stopping the server. Yes, there is always the risk of someone starting the server while it is down during pg_upgrade; we assume the user has control of others starting the server during pg_upgrade. > > Also, no one has explained how not knowing if -o > > options were used was a safe. > > Hmm, good point. But we already have this problem -- see above. Yes, also true. I guess I can only stay it works for -w. :-( -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
>>> I don't think I like --force because it isn't clear if we are forcing >>> the start to have done something, or forcing the server to be running. > > Do we need this idempotent feature for "stop" too? Yes, of course. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, Jan 30, 2013 at 04:07:45PM +1100, Josh Berkus wrote: > > >>> I don't think I like --force because it isn't clear if we are forcing > >>> the start to have done something, or forcing the server to be running. > > > > Do we need this idempotent feature for "stop" too? > > Yes, of course. If idempotent only affects -w (we don't wait for the return code without -w), can we make -W to be idempotent? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Mon, 2013-01-14 at 06:37 -0500, Peter Eisentraut wrote: > Here is a patch to add an option -I/--idempotent to pg_ctl, the result > of which is that pg_ctl doesn't error on start or stop if the server is > already running or already stopped. So apparently, pg_upgrade needs the existing behavior, so making the idempotent option the only behavior won't work. Therefore, I think this patch is still useful as originally presented. I've made one change that pg_ctl won't print any messages if the -I option is used and the server is already started/stopped.