Re: pgsql: Get rid of the dedicated latch for signaling the startup process
| От | Fujii Masao |
|---|---|
| Тема | Re: pgsql: Get rid of the dedicated latch for signaling the startup process |
| Дата | |
| Msg-id | 8f02685c-4029-c038-8bbb-99fe22d09379@oss.nttdata.com обсуждение исходный текст |
| Ответ на | Re: pgsql: Get rid of the dedicated latch for signaling the startup process (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: pgsql: Get rid of the dedicated latch for signaling the startup process
|
| Список | pgsql-committers |
On 2020/11/05 5:36, Heikki Linnakangas wrote:
> 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
highlyunlikely to happen in practice because the compiler will optimize that into a single load instruction, but could
happenwith -O0. I think you'd need to do the access only once, using a volatile pointer, to make that safe. Maybe it's
simplerto just not reset it to NULL, after all.
Yes, you're right. I agree it's simpler to remove the code resetting
the latch to NULL. Also as the comment for that code explains,
basically it's not necessary to reset it to NULL.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
В списке pgsql-committers по дате отправления: