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

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.