Re: pg_ctl idempotent option

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



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: COPY FREEZE has no warning
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: bugfix: --echo-hidden is not supported by \sf statements