pgsql: Be more careful about barriers when releasing BackgroundWorkerSl

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Be more careful about barriers when releasing BackgroundWorkerSl
Дата
Msg-id E1lhx2f-00083P-8e@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Be more careful about barriers when releasing BackgroundWorkerSlots.

ForgetBackgroundWorker lacked any memory barrier at all, while
BackgroundWorkerStateChange had one but unaccountably did
additional manipulation of the slot after the barrier.  AFAICS,
the rule must be that the barrier is immediately before setting
or clearing slot->in_use.

It looks like back in 9.6 when ForgetBackgroundWorker was first
written, there might have been some case for not needing a
barrier there, but I'm not very convinced of that --- the fact
that the load of bgw_notify_pid is in the caller doesn't seem
to guarantee no memory ordering problem.  So patch 9.6 too.

It's likely that this doesn't fix any observable bug on Intel
hardware, but machines with weaker memory ordering rules could
have problems here.

Discussion: https://postgr.es/m/4046084.1620244003@sss.pgh.pa.us

Branch
------
REL_12_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/6bcb51968c2719063b31c95b339a071a392c4beb

Modified Files
--------------
src/backend/postmaster/bgworker.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)


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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: pgsql: Harden nbtree deduplication posting split code.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: pgsql: Allow compute_query_id to be set to 'auto' and make it default