Re: pg_ctl idempotent option - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_ctl idempotent option
Date
Msg-id 20130129125703.GA10089@momjian.us
Whole thread Raw
In response to Re: pg_ctl idempotent option  (Josh Berkus <josh@agliodbs.com>)
Responses Re: pg_ctl idempotent option
List pgsql-hackers
On Tue, Jan 29, 2013 at 04:19:15PM +1100, Josh Berkus wrote:
> 
> > 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 success
> >     server start failed
> >     server 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.
> 
> Not sure if that would work.  Too many admin scripts only check for
> error output, and not what the error code was.
> 
> FWIW, the Solaris/Opensolaris service scripts, as well as the RH service
> scripts (I think), already handle things this way.  If you say:
> 
> svcadm enable postgresql
> 
> ... and postgres is already up, it just returns 0.  So it's a common
> pattern.
> 
> So, alternate suggestions to "idempotent":
> 
> --isup
> --isrunning
> --ignorerunning
> 
> However, I'm really beginnging to think that a switch isn't correct, and
> what we need to do is to have a different pg_ctl *command*, e.g.:
> 
> pg_ctl -D . on
> or
> pg_ctl -D . enable

Yeah, that makes a lot of sense.

> > 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.

Do we need this idempotent feature for "stop" too?

--  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: Jeevan Chalke
Date:
Subject: Re: unlogged tables vs. GIST
Next
From: Kohei KaiGai
Date:
Subject: Re: [sepgsql 2/3] Add db_schema:search permission checks