From 61480441f67ca7fac96ca4bcfe85f27013a47aa8 Mon Sep 17 00:00:00 2001 From: Thomas Munro Date: Tue, 6 Dec 2022 16:13:36 +1300 Subject: [PATCH v4 2/5] Don't leak a signalfd when using latches in the postmaster. At the time of commit 6a2a70a02 we didn't use latch infrastructure in the postmaster. We're planning to start doing that, so we'd better make sure that the signalfd inherited from a postmaster is not duplicated and then leaked in the child. Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKG%2BZ-HpOj1JsO9eWUP%2Bar7npSVinsC_npxSy%2BjdOMsx%3DGg%40mail.gmail.com --- src/backend/storage/ipc/latch.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/backend/storage/ipc/latch.c b/src/backend/storage/ipc/latch.c index 7ced8264f0..c4b9153690 100644 --- a/src/backend/storage/ipc/latch.c +++ b/src/backend/storage/ipc/latch.c @@ -283,6 +283,22 @@ InitializeLatchSupport(void) #ifdef WAIT_USE_SIGNALFD sigset_t signalfd_mask; + if (IsUnderPostmaster) + { + /* + * It would probably be safe to re-use the inherited signalfd since + * signalfds only see the current processes pending signals, but it + * seems less surprising to close it and create our own. + */ + if (signal_fd != -1) + { + /* Release postmaster's signal FD; ignore any error */ + (void) close(signal_fd); + signal_fd = -1; + ReleaseExternalFD(); + } + } + /* Block SIGURG, because we'll receive it through a signalfd. */ sigaddset(&UnBlockSig, SIGURG); -- 2.30.2