Re: pgsql: Get rid of the dedicated latch for signaling the startup process

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: pgsql: Get rid of the dedicated latch for signaling the startup process
Дата
Msg-id 3d3c42ca-c1bd-605d-71cf-8cd6353e895b@iki.fi
обсуждение исходный текст
Ответ на 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  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список 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



В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Declare lead() and lag() using anycompatible not anyelement.
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: pgsql: Get rid of the dedicated latch for signaling the startup process