In the postmaster, rely on the signal infrastructure to block signals

Enterprise / PostgreSQL - Tom Lane [sss.pgh.pa.us] - 13 October 2019 19:48 EDT

POSIX sigaction(2) can be told to block a set of signals while a signal handler executes. Make use of that instead of manually blocking and unblocking signals in the postmaster's signal handlers. This should save a few cycles, and it also prevents recursive invocation of signal handlers when many signals arrive in close succession. We have seen buildfarm failures that seem to be due to postmaster stack overflow caused by such recursion (exacerbated by a Linux PPC64 kernel bug).

This doesn't change anything about the way that it works on Windows. Somebody might consider adjusting port/win32/signal.c to let it work similarly, but I'm not in a position to do that.

For the moment, just apply to HEAD. Possibly we should consider back-patching this, but it'd be good to let it age awhile first.

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

9abb2bfc04 In the postmaster, rely on the signal infrastructure to block signals.
src/backend/libpq/pqsignal.c | 49 +++++++++++++++++++++
src/backend/postmaster/postmaster.c | 87 +++++++++++++++++++++++++++----------
src/include/libpq/pqsignal.h | 3 ++
src/include/port.h | 5 ---
src/port/pqsignal.c | 29 -------------
5 files changed, 116 insertions(+), 57 deletions(-)

Upstream: git.postgresql.org


  • Share