Re: [bug fix] "pg_ctl stop" times out when it should respond quickly

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [bug fix] "pg_ctl stop" times out when it should respond quickly
Дата
Msg-id CAB7nPqRKSCfj9dYpCgGfNqaRXYXNi9RhRJOrP62bVyAAmtXXAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [bug fix] "pg_ctl stop" times out when it should respond quickly  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Feb 18, 2014 at 1:29 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> MauMau escribió:
> The pg_regress part is ugly.  However, pg_regress is doing something
> unusual when starting postmaster itself, so the ugly coding to stop it
> seems to match.  If we wanted to avoid the ugliness here, the right fix
> would be to use pg_ctl to start postmaster as well as to stop it.  But
> that'd come at a price, because we would need more ugly code to figure
> out postmaster's PID.  All in all, the compromise proposed by this patch
> seems acceptable.  If we really wanted to make all this real pretty, we
> could provide a "libpg_ctl" library to start and stop postmaster, as
> well as query the PID.  Probably not worth the trouble.
This might not be worth the trouble for this bug, but actually it
could be useful to many third-part tools and extensions to have a
common and generic way to do things. I have seen many utilities using
a copy/paste of pg_ctl functions and still maintain some of them...
Regards,
--
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Description for pg_replslot in docs
Следующее
От: Shigeru Hanada
Дата:
Сообщение: Re: inherit support for foreign tables