Re: [HACKERS] Reducing pg_ctl's reaction time

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Reducing pg_ctl's reaction time
Дата
Msg-id 20871.1498595175@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Reducing pg_ctl's reaction time  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-06-27 14:59:18 -0400, Tom Lane wrote:
>> If we decide that it has to wait for v11,
>> I'd address Jeff's complaint by hacking the loop behavior in
>> test_postmaster_connection, which'd be ugly but not many lines of code.

> Basically increasing the wait time over time?

I was thinking of just dropping back to once-per-second after a couple
of seconds, with something along the lines of this in place of the
existing sleep at the bottom of the loop:
if (i >= 2 * WAITS_PER_SEC){    pg_usleep(USEC_PER_SEC);    i += WAITS_PER_SEC - 1;}else    pg_usleep(USEC_PER_SEC /
WAITS_PER_SEC);


> The 8-space thing in multiple places is a bit ugly.  How about having a
> a bunch of constants declared in one place? Alternatively make it
> something like: status: $c, where $c is a one character code for the
> various states?

Yeah, we could add the string values as macros in miscadmin.h, perhaps.
I don't like the single-character idea --- if we do expand the number of
things reported this way, that could get restrictive.
        regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Reducing pg_ctl's reaction time
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?