Re: pg_ctl idempotent option

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: pg_ctl idempotent option
Дата
Msg-id 51075BD3.3000201@agliodbs.com
обсуждение исходный текст
Ответ на Re: pg_ctl idempotent option  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: pg_ctl idempotent option  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Re: pg_ctl idempotent option  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
> 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 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: autovacuum not prioritising for-wraparound tables
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: psql \l to accept patterns