Re: pg_ctl idempotent option - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: pg_ctl idempotent option
Date
Msg-id CAFjFpRcomg147eYNQ0Z2-zkhjzKnf=d-0zAWP5dCxp6UOhjY6A@mail.gmail.com
Whole thread Raw
In response to Re: pg_ctl idempotent option  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers


On Tue, Jan 29, 2013 at 10:49 AM, Josh Berkus <josh@agliodbs.com> 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

I doubt if that would help much. We will need to coin a new command for stop as well. A new pg_ctl command would confuse user as to what it should be using "on" or "start" in a given scenario. I think switch is better. Above switches won't look good with stop. We need some word/phrase which is good for both start and stop commands.
 
> 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.

Agfeed.


--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

pgsql-hackers by date:

Previous
From: Alexander Law
Date:
Subject: Re: BUG #7493: Postmaster messages unreadable in a Windows console
Next
From: Dean Rasheed
Date:
Subject: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used