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 15166.1498512630@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  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@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.

> 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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Reducing pg_ctl's reaction time
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Reducing pg_ctl's reaction time