Re: pg_ctl idempotent option

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_ctl idempotent option
Дата
Msg-id 20130123185609.GA23670@momjian.us
обсуждение исходный текст
Ответ на Re: pg_ctl idempotent option  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: pg_ctl idempotent option  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список 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@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. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gavin Flower
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)