Re: pg_ctl idempotent option

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_ctl idempotent option
Date: 2013-01-23 18:56:09
Message-ID: 20130123185609.GA23670@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-01-23 18:58:24 Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Previous Message Gavin Flower 2013-01-23 18:53:41 Re: Support for REINDEX CONCURRENTLY