pgsql: Avoid potential spinlock in a signal handler as part of global b

Поиск
Список
Период
Сортировка
От Andres Freund
Тема pgsql: Avoid potential spinlock in a signal handler as part of global b
Дата
Msg-id E1jle2C-0005Cz-3D@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Avoid potential spinlock in a signal handler as part of global barriers.

On platforms without support for 64bit atomic operations where we also
cannot rely on 64bit reads to have single copy atomicity, such atomics
are implemented using a spinlock based fallback. That means it's not
safe to even read such atomics from within a signal handler (since the
signal handler might run when the spinlock already is held).

To avoid this issue defer global barrier processing out of the signal
handler. Instead of checking local / shared barrier generation to
determine whether to set ProcSignalBarrierPending, introduce
PROCSIGNAL_BARRIER and always set ProcSignalBarrierPending when
receiving such a signal. Additionally avoid redundant work in
ProcessProcSignalBarrier if ProcSignalBarrierPending is unnecessarily.

Also do a small amount of other polishing.

Author: Andres Freund
Reviewed-By: Robert Haas
Discussion: https://postgr.es/m/20200609193723.eu5ilsjxwdpyxhgz@alap3.anarazel.de
Backpatch: 13-, where the code was introduced.

Branch
------
REL_13_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/09bff91b316e90bf7f523593c1e8000c772cbe52

Modified Files
--------------
src/backend/storage/ipc/procsignal.c | 87 +++++++++++++++++++++---------------
src/include/storage/procsignal.h     |  1 +
2 files changed, 52 insertions(+), 36 deletions(-)


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: pgsql: Avoid potential spinlock in a signal handler as part of global b
Следующее
От: Andres Freund
Дата:
Сообщение: pgsql: spinlock emulation: Fix bug when more than INT_MAX spinlocks are