Re: [HACKERS] Reducing pg_ctl's reaction time
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Reducing pg_ctl's reaction time |
Дата | |
Msg-id | 15732.1498513083@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
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2017-06-26 17:30:30 -0400, Tom Lane wrote: >> No, I don't like that at all. Has race conditions against updates >> coming from the startup process. > You'd obviously have to take the appropriate locks. I think the issue > here is less race conditions, and more that architecturally we'd > interact with shmem too much. Uh, we are *not* taking any locks in the postmaster. >> Yeah, that would be a different way to go at it. The postmaster would >> probably just write the state of the hot_standby GUC to the file, and >> pg_ctl would have to infer things from there. > I'd actually say we should just mirror the existing > #ifdef USE_SYSTEMD > if (!EnableHotStandby) > sd_notify(0, "READY=1"); > #endif > with corresponding pidfile updates - doesn't really seem necessary for > pg_ctl to do more? 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. regards, tom lane
В списке pgsql-hackers по дате отправления: