Re: [HACKERS] Reducing pg_ctl's reaction time
От | Jeff Janes |
---|---|
Тема | Re: [HACKERS] Reducing pg_ctl's reaction time |
Дата | |
Msg-id | CAMkU=1wrMqPggnEfszE-c3PPLmKgRK17_qr7tmxBECYEbyV-4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Reducing pg_ctl's reaction time (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Reducing pg_ctl's reaction time
Re: [HACKERS] Reducing pg_ctl's reaction time |
Список | pgsql-hackers |
On Tue, Jun 27, 2017 at 11:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
> 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.
Here's a draft patch for that. I quite like the results --- this seems
way simpler and more reliable than what pg_ctl has done up to now.
However, it's certainly arguable that this is too much change for an
optional post-beta patch.
In the now-committed version of this, the 'pg_ctl start' returns successfully as soon as the server reaches a consistent state. Which is OK, except that it does the same thing when hot_standby=off. When hot_standby=off, I would expect it to wait for the end of recovery before exiting with a success code.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: