On 2017-06-26 17:30:30 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > It'd be quite possible to address the race-condition by moving the
> > updating of the control file to postmaster, to the
> > CheckPostmasterSignal(PMSIGNAL_BEGIN_HOT_STANDBY) block. That'd require
> > updating the control file from postmaster, which'd be somewhat ugly.
>
> 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.
> > Perhaps that indicates that field shouldn't be in pg_control, but in the
> > pid file?
>
> 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?
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
