Re: pg_ctl idempotent option

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(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-23 19:06:45
Message-ID: 20130123190645.GD23670@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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 Brar Piening 2013-01-23 19:23:32 Re: Visual Studio 2012 RC
Previous Message Pavel Stehule 2013-01-23 19:06:36 Re: bugfix: --echo-hidden is not supported by \sf statements