Re: pg_ctl idempotent option

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, 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-24 03:35:59
Message-ID: CAFjFpRc91ovkqTJqyaLgUV+SZebLqBJHn-x5Y6Ve6JpF9R=s9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)momjian(dot)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(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-24 04:13:33 Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Previous Message Craig Ringer 2013-01-24 03:28:35 Re: Visual Studio 2012 RC