Re: pg_ctl idempotent option
От | Ashutosh Bapat |
---|---|
Тема | Re: pg_ctl idempotent option |
Дата | |
Msg-id | CAFjFpRcomg147eYNQ0Z2-zkhjzKnf=d-0zAWP5dCxp6UOhjY6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_ctl idempotent option (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Tue, Jan 29, 2013 at 10:49 AM, Josh Berkus <josh@agliodbs.com> wrote:
Not sure if that would work. Too many admin scripts only check for
> 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.
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 forcingAgfeed.
> the start to have done something, or forcing the server to be running.--
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 по дате отправления: