Re: pgsql: Use SIGURG rather than SIGUSR1 for latches.

On Sat, Apr 17, 2021 at 12:46 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.