From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Fujii Masao <fujii(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Get rid of the dedicated latch for signaling the startup process |
Date: | 2020-11-04 20:36:14 |
Message-ID: | 3d3c42ca-c1bd-605d-71cf-8cd6353e895b@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 04/11/2020 15:17, Heikki Linnakangas wrote:
> On 04/11/2020 14:03, Fujii Masao wrote:
>> Or ISTM that WakeupRecovery() should set the latch only when the latch
>> has not been reset to NULL yet.
>
> Got to be careful with race conditions, if the latch is set to NULL at
> the same time that WakeupRecovery() is called.
I don't think commit 113d3591b8 got this quite right:
> void
> WakeupRecovery(void)
> {
> if (XLogCtl->recoveryWakeupLatch)
> SetLatch(XLogCtl->recoveryWakeupLatch);
> }
If XLogCtl->recoveryWakeupLatch is set to NULL between the if and the
SetLatch, you'll still get a segfault. That's highly unlikely to happen
in practice because the compiler will optimize that into a single load
instruction, but could happen with -O0. I think you'd need to do the
access only once, using a volatile pointer, to make that safe. Maybe
it's simpler to just not reset it to NULL, after all.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-11-04 21:02:05 | Re: pgsql: Get rid of the dedicated latch for signaling the startup process |
Previous Message | Tom Lane | 2020-11-04 20:08:48 | pgsql: Declare lead() and lag() using anycompatible not anyelement. |