Re: pg_ctl idempotent option - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_ctl idempotent option
Date
Msg-id 20130129024727.GA3313@momjian.us
Whole thread Raw
In response to Re: pg_ctl idempotent option  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_ctl idempotent option
List pgsql-hackers
On Mon, Jan 28, 2013 at 09:29:35PM -0500, Bruce Momjian wrote:
> On Mon, Jan 28, 2013 at 03:40:08PM +0000, Simon Riggs wrote:
> > On 14 January 2013 15:29, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > > Tom Lane wrote:
> > >> Peter Eisentraut <peter_e@gmx.net> writes:
> > >> > Here is a patch to add an option -I/--idempotent to pg_ctl, the result
> > >> > of which is that pg_ctl doesn't error on start or stop if the server is
> > >> > already running or already stopped.
> > >>
> > >> Idempotent is a ten-dollar word.  Can we find something that average
> > >> people wouldn't need to consult a dictionary to understand?
> > >
> > > --no-error perhaps?
> > 
> > 
> > I think --force  would be the accepted way to ensure something happens
> > as specified
> > 
> > 
> > Mind you, I'm not sure I see the value in throwing an error if the
> > server is in the desired state already. Who actually wants that
> > behaviour? Can't we just change the behaviour? Existing scripts would
> > still work, since we are simply skipping an error.
> 
> pg_upgrade uses that to find out of the server was already running or if
> we started it.  This is to start the server to remove the
> postmaster.pid file.  Also, no one has explained how not knowing if -o
> options were used was a safe.

OK, I had some time to think about this.  Basically, we have three
outcomes for pg_ctl start:
server not running and pg_ctl start successserver start failedserver already running

Can't we just assign different return values to these cases, e.g. 0, 1,
2?  We already print output telling the user what happened.

I don't think I like --force because it isn't clear if we are forcing
the start to have done something, or forcing the server to be running.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT
Next
From: Robert Haas
Date:
Subject: Re: autovacuum not prioritising for-wraparound tables