Process pending postmaster work before connections.
authorThomas Munro <tmunro@postgresql.org>
Wed, 25 Jan 2023 01:28:01 +0000 (14:28 +1300)
committerThomas Munro <tmunro@postgresql.org>
Wed, 25 Jan 2023 02:00:05 +0000 (15:00 +1300)
commit239b1753421ccbd52f4f628a9265c3034d38b80f
treec0ff6cf19acfce0ecb3abd5449cd44d75a5ef52c
parent8f8f11593258d04e9a58365865f7daf123e24bb1
Process pending postmaster work before connections.

Modify the new event loop code from commit 7389aad6 so that it checks
for work requested by signal handlers even if it doesn't see a latch
event yet.

This gives priority to shutdown and reload requests where the latch will
be reported later in the event array, or in a later call to
WaitEventSetWait(), due to scheduling details.  In particular, this
guarantees that a SIGHUP-then-connect sequence (as seen in
authentication tests) causes the postmaster to process the reload before
accepting the connection.  If the WaitEventSetWait() call saw the socket
as ready, and the reload signal was generated before the connection,
then the latest time the signal handler should be able to run is after
poll/epoll_wait/kevent returns but before we check the
pending_pm_reload_request flag.

While here, also shift the handling of child exit below reload requests,
per Tom Lane's observation that that might start new processes, so we
should make sure we pick up new settings first.

This probably explains the one-off failure of build farm animal
malleefowl.

Reported-by: Hou Zhijie <houzj.fnst@fujitsu.com>
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/OS0PR01MB57163D3BF2AB42ECAA94E5C394C29%40OS0PR01MB5716.jpnprd01.prod.outlook.com
src/backend/postmaster/postmaster.c