On Sat, Apr 17, 2021 at 12:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It might be good to extend the comment in postmaster.c though, perhaps
> along the lines of "Ignore SIGURG for now. Child processes may change
> this (see InitializeLatchSupport), but they will not receive any such
> signals until they wait on a latch".
Ok, will do.
> Is it really necessary to mess with UnBlockSig?
It's necessary to keep it blocked, because, to quote signalfd(2):
Normally, the set of signals to be received via the file descriptor
should be blocked using sigprocmask(2), to prevent the signals being
handled according to their default dispositions.
It does seem a little strange to have a sigset_t called UnBlockSig
that leaves one signal blocked, but it still fits this description
(from which I removed the parenthetical question):
* UnBlockSig is the set of signals to block when we don't want to block
- * signals (is this ever nonzero??)
+ * signals.
There is also clear warning near that:
+ /* Note: InitializeLatchSupport() modifies UnBlockSig. */
I admit that it's a little unpleasant that it does that, but I
couldn't find a better way, considering the dependency on build
options and details known only to latch.c. In earlier versions I
posted of that patch set, I did consider an alternative where
pqsignal.c would ask latch.c if it should be blocked, but it seemed
uglier.
The kqueue designers made a different choice for EVFILT_SIGNAL:
... This coexists with the signal() and
sigaction() facilities, and has a lower precedence.
The filter will record all attempts to deliver a
signal to a process, even if the signal has been
marked as SIG_IGN, ...
So in kqueue builds, it's not necessary to block it, because SIG_IGN
is enough to redirect the signal to the kqueue (and blocking it would
prevent kqueue from receiving it IIRC). All the calls to set the
disposition to SIG_IGN explicitly are probably unnecessary since
that's the default disposition, but I figured that was somehow useful
as documentation, and a place to hang a comment.
