| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reducing pg_ctl's reaction time |
| Date: | 2017-06-26 21:30:30 |
| Message-ID: | 15166.1498512630@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-06-26 21:34:14 | Re: Reducing pg_ctl's reaction time |
| Previous Message | Andres Freund | 2017-06-26 20:58:53 | Re: Reducing pg_ctl's reaction time |