Re: Replace known_assigned_xids_lck by memory barrier

Поиск
Список
Период
Сортировка
От Michail Nikolaev
Тема Re: Replace known_assigned_xids_lck by memory barrier
Дата
Msg-id CANtu0ogdo86z-+oQVT7LENPPe_W4N5Q4HsisM_Xpf-H=v5vaow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Replace known_assigned_xids_lck by memory barrier  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: Replace known_assigned_xids_lck by memory barrier  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
Hello!

Updated version (with read barriers is attached).

> One remaining question I have is whether it is okay if we see an updated value
> for one of the head/tail variables but not the other.  It looks like the
> tail variable is only updated with ProcArrayLock held exclusively, which
> IIUC wouldn't prevent such mismatches even today, since we use a separate
> spinlock for reading them in some cases.

1) "The convention is that backends must hold shared ProcArrayLock to
examine the array", it is applied to pointers as well
2) Also, "only the startup process modifies the head/tail pointers."

So, the "tail" variable is updated by the startup process with
ProcArrayLock held in exclusive-only mode - so, no issues here.

Regarding "head" variable -  updates by the startup processes are
possible in next cases:
* ProcArrayLock in exclusive mode (like KnownAssignedXidsCompress or
KnownAssignedXidsSearch(remove=true)), no issues here
* ProcArrayLock not taken at all (like
KnownAssignedXidsAdd(exclusive_lock=false)) in such case we rely on
memory barrier machinery

Both head and tail variables are changed only with exclusive lock held.

I'll think more, but can't find something wrong here so far.

Вложения

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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: should frontend tools use syncfs() ?
Следующее
От: jian he
Дата:
Сообщение: Re: Extract numeric filed in JSONB more effectively