Use WaitEventSet API for postmaster's event loop.
authorThomas Munro <tmunro@postgresql.org>
Wed, 11 Jan 2023 23:34:23 +0000 (12:34 +1300)
committerThomas Munro <tmunro@postgresql.org>
Thu, 12 Jan 2023 03:32:20 +0000 (16:32 +1300)
commit7389aad63666a2cac18cd6d7496378d7f50ef37b
treedfcfb672a82df147e9e73a536332eb7dd5a2770d
parentd93d68aeeaeeda0e871825b461fd9ab68c7c0de3
Use WaitEventSet API for postmaster's event loop.

Switch to a design similar to regular backends, instead of the previous
arrangement where signal handlers did non-trivial state management and
called fork().  The main changes are:

* The postmaster now has its own local latch to wait on.  (For now, we
  don't want other backends setting its latch directly, but that could
  probably be made to work with more research on robustness.)

* The existing signal handlers are cut in two: a handle_pm_XXX() part
  that just sets pending_pm_XXX flags and the latch, and a
  process_pm_XXX() part that runs later when the latch is seen.

* Signal handlers are now installed with the regular pqsignal()
  function rather than the special pqsignal_pm() function; historical
  portability concerns about the effect of SA_RESTART on select() are no
  longer relevant, and we don't need to block signals anymore.

Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CA%2BhUKG%2BZ-HpOj1JsO9eWUP%2Bar7npSVinsC_npxSy%2BjdOMsx%3DGg%40mail.gmail.com
src/backend/libpq/pqcomm.c
src/backend/libpq/pqsignal.c
src/backend/postmaster/fork_process.c
src/backend/postmaster/postmaster.c
src/backend/tcop/postgres.c
src/backend/utils/init/miscinit.c
src/include/libpq/pqsignal.h
src/include/miscadmin.h