Re: pg_ctl idempotent option

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_ctl idempotent option
Date: 2013-01-29 12:57:03
Message-ID: 20130129125703.GA10089@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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 Simon Riggs 2013-01-29 13:23:29 Re: pgsql: Fast promote mode skips checkpoint at end of recovery.
Previous Message Jeevan Chalke 2013-01-29 12:33:58 Re: unlogged tables vs. GIST