Hi, On 2017-06-26 16:49:07 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Arguably we could and should improve the logic when the server has > > started, right now it's pretty messy because we never treat a standby as > > up if hot_standby is disabled... > > True. If you could tell the difference between "HS disabled" and "HS not > enabled yet" from pg_control, that would make pg_ctl's behavior with > cold-standby servers much cleaner. Maybe it *is* worth messing with the > contents of pg_control at this late hour.
I'm +0.5. > My inclination for the least invasive fix is to leave the DBState > enum alone and add a separate hot-standby state field with three > values (disabled/not-yet-enabled/enabled). Yea, that seems sane. > Then pg_ctl would start > probing the postmaster when it saw either DB_IN_PRODUCTION DBstate > or hot-standby-enabled. (It'd almost not have to probe the postmaster > at all, except there's a race condition that the startup process > will probably change the field a little before the postmaster gets > the word to open the gates.) On the other hand, if it saw > DB_IN_ARCHIVE_RECOVERY with hot standby disabled, it'd stop waiting. 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. Perhaps that indicates that field shouldn't be in pg_control, but in the pid file? 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
