Re: [HACKERS] Reducing pg_ctl's reaction time - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Reducing pg_ctl's reaction time
Date
Msg-id 17327.1498515236@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Reducing pg_ctl's reaction time  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Reducing pg_ctl's reaction time  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Timing-sensitive case in src/test/recovery TAP tests