Thread

pg_ctl idempotent option

Peter Eisentraut <peter_e@gmx.net> — 2013-01-14T11:37:58Z

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

Re: pg_ctl idempotent option

Tom Lane <tgl@sss.pgh.pa.us> — 2013-01-14T15:22:48Z

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

Re: pg_ctl idempotent option

Alvaro Herrera <alvherre@2ndquadrant.com> — 2013-01-14T15:29:53Z

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

Re: pg_ctl idempotent option

Tom Lane <tgl@sss.pgh.pa.us> — 2013-01-14T15:47:12Z

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

Re: pg_ctl idempotent option

Thom Brown <thom@linux.com> — 2013-01-14T15:48:57Z

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

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

Re: pg_ctl idempotent option

Boszormenyi Zoltan <zb@cybertec.at> — 2013-01-14T16:49:49Z

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/

Re: pg_ctl idempotent option

Dickson S. Guedes <listas@guedesoft.net> — 2013-01-15T10:14:36Z

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

Re: pg_ctl idempotent option

Vik Reykja <vikreykja@gmail.com> — 2013-01-15T10:26:28Z

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.

Vik

Re: pg_ctl idempotent option

Alvaro Herrera <alvherre@2ndquadrant.com> — 2013-01-15T12:53:21Z

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

Re: pg_ctl idempotent option

Tom Lane <tgl@sss.pgh.pa.us> — 2013-01-15T15:25:23Z

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

Re: pg_ctl idempotent option

Peter Eisentraut <peter_e@gmx.net> — 2013-01-15T15:51:53Z

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.

Re: pg_ctl idempotent option

Peter Eisentraut <peter_e@gmx.net> — 2013-01-15T15:55:41Z

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.

Re: pg_ctl idempotent option

Tom Lane <tgl@sss.pgh.pa.us> — 2013-01-15T16:06:44Z

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

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-15T19:28:56Z

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. +

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-15T19:29:45Z

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. +

Re: pg_ctl idempotent option

Boszormenyi Zoltan <zb@cybertec.at> — 2013-01-15T19:36:39Z

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/

Re: pg_ctl idempotent option

Josh Berkus <josh@agliodbs.com> — 2013-01-15T20:50:09Z

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

Re: pg_ctl idempotent option

Michael Paquier <michael.paquier@gmail.com> — 2013-01-15T23:48:16Z

On Wed, Jan 16, 2013 at 4:29 AM, Bruce Momjian <bruce@momjian.us> wrote:

> That's Japanese for idempotent.  ;-)  LOL
>
+1.
-- 
Michael Paquier
http://michael.otacoo.com

Re: pg_ctl idempotent option

Phil Sorber <phil@omniti.com> — 2013-01-19T01:48:08Z

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

Re: pg_ctl idempotent option

Phil Sorber <phil@omniti.com> — 2013-01-21T15:54:41Z

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?

Re: pg_ctl idempotent option

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2013-01-22T12:33:28Z

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

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-23T18:56:09Z

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. +

Re: pg_ctl idempotent option

Heikki Linnakangas <hlinnakangas@vmware.com> — 2013-01-23T19:00:25Z

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

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-23T19:06:45Z

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. +

Re: pg_ctl idempotent option

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2013-01-24T03:35:59Z

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

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-24T13:06:10Z

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. +

Re: pg_ctl idempotent option

Simon Riggs <simon@2ndquadrant.com> — 2013-01-28T15:40:08Z

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

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-29T02:29:35Z

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. +

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-29T02:47:27Z

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

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. +

Re: pg_ctl idempotent option

Josh Berkus <josh@agliodbs.com> — 2013-01-29T05:19:15Z

> 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

Re: pg_ctl idempotent option

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2013-01-29T06:32:58Z

On Tue, Jan 29, 2013 at 10:49 AM, Josh Berkus <josh@agliodbs.com> 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
>
> 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 forcing
> > the start to have done something, or forcing the server to be running.
>
> Agfeed.
>
>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
>
> --
> 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

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-29T12:57:03Z

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. +

Re: pg_ctl idempotent option

Dimitri Fontaine <dimitri@2ndquadrant.fr> — 2013-01-29T16:03:39Z

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

Re: pg_ctl idempotent option

Peter Eisentraut <peter_e@gmx.net> — 2013-01-29T21:34:50Z

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.

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-29T22:03:08Z

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 start
	pg_ctl: another server might be running; trying to start server anyway
	server starting
	# FATAL:  lock file "postmaster.pid" already exists
	HINT:  Is another postmaster (PID 14144) running in data directory "/u/pgsql/data"?
	# echo $?
	0
	
	# pg_ctl -w start
	pg_ctl: another server might be running; trying to start server anyway
	waiting for server to start....FATAL:  lock file "postmaster.pid" already exists
	HINT:  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 waiting
	pg_ctl: could not start server
	Examine 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. +

Re: pg_ctl idempotent option

Josh Berkus <josh@agliodbs.com> — 2013-01-30T05:07:45Z

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

Re: pg_ctl idempotent option

Bruce Momjian <bruce@momjian.us> — 2013-01-30T21:35:11Z

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. +

Re: pg_ctl idempotent option

Peter Eisentraut <peter_e@gmx.net> — 2013-03-06T04:37:17Z

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.