Re: [HACKERS] Reducing pg_ctl's reaction time

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Reducing pg_ctl's reaction time
Дата
Msg-id 17327.1498515236@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Reducing pg_ctl's reaction time  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Reducing pg_ctl's reaction time  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-06-26 17:38:03 -0400, Tom Lane wrote:
>> Hm.  Take that a bit further, and we could drop the connection probes
>> altogether --- just put the whole responsibility on the postmaster to
>> show in the pidfile whether it's ready for connections or not.

> Yea, that seems quite appealing, both from an architectural, simplicity,
> and log noise perspective. I wonder if there's some added reliability by
> the connection probe though? Essentially wondering if it'd be worthwhile
> to keep a single connection test at the end. I'm somewhat disinclined
> though.

I agree --- part of the appeal of this idea is that there could be a net
subtraction of code from pg_ctl.  (I think it wouldn't have to link libpq
anymore at all, though maybe I forgot something.)  And you get rid of a
bunch of can't-connect failure modes, eg kernel packet filter in the way,
which probably outweighs any hypothetical reliability gain from confirming
the postmaster state the old way.

This would mean that v10 pg_ctl could not be used to start/stop older
postmasters, which is flexibility we tried to preserve in the past.
But I see that we already gave that up in quite a few code paths because
of their attempts to read pg_control, so I think it's a concern we can
ignore.

I'll draft something up later.
        regards, tom lane



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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests