[PATCH] Optimize ProcSignal to avoid redundant SIGUSR1 signals

Hi hackers,

In the work of trying to optimize async.c, I came across a surprisingly
seemingly low hanging fruit in procsignal.c, to $subject.

This optimization improves not only LISTEN/NOTIFY,
but procsignal.c in general, for all ProcSignalReasons,
by avoiding to send redundant signals in the case
when the backend hasn't received and handled them yet.

--- PATCH ---

Previously, ProcSignal used an array of volatile sig_atomic_t flags, one
per signal reason. A sender would set a flag and then unconditionally
send a SIGUSR1 to the target process. This could result in a storm of
redundant signals if multiple processes signaled the same target before
it had a chance to run its signal handler.

Change this to use a single pg_atomic_uint32 as a bitmask of pending
signals. When sending, use pg_atomic_fetch_or_u32 to set the appropriate
signal bit and inspect the prior state of the flags word. Then only
issue a SIGUSR1 if the previous flags state was zero. This works safely
because the receiving backend's signal handler atomically resets the
entire bitmask upon receipt, thus processing all pending signals at
once. Consequently, subsequent senders seeing a nonzero prior state know
a signal is already in flight, significantly reducing redundant
kill(pid, SIGUSR1) system calls under heavy contention.

On the receiving end, the SIGUSR1 handler now atomically fetches and
clears the entire bitmask with a single pg_atomic_exchange_u32, then
calls the appropriate sub-handlers.

The further optimization to only check if the old flags word was zero is
due to Andreas Karlsson.

--- BENCHMARK ---

The attached benchmark script does LISTEN on one connection,
and then uses pgbench to send NOTIFY on a varying number of
connections and jobs, to cause a high procsignal load.

I've run the benchmark on my MacBook Pro M3 Max,
10 seconds per run, 3 runs.

 Connections=Jobs | TPS (master) | TPS (patch) | Relative Diff (%) | StdDev (master) | StdDev (patch)
------------------+--------------+-------------+-------------------+-----------------+----------------
                1 |       118833 |      118902 | 0.06%             |             484 |            520
                2 |       156005 |      194873 | 24.91%            |            3145 |            631
                4 |       177351 |      190672 | 7.51%             |            4305 |           1439
                8 |       116597 |      124793 | 7.03%             |            1549 |           1011
               16 |        40835 |      113312 | 177.49%           |            2695 |           1155
               32 |        37940 |      108469 | 185.90%           |            2533 |            487
               64 |        35495 |      104994 | 195.80%           |            1837 |            318
              128 |        40193 |      100246 | 149.41%           |            2254 |            393
(8 rows)


Raw Data Summary:
 Version  | Connections | Runs | Min TPS | Max TPS | Avg TPS
----------+-------------+------+---------+---------+---------
 master   |           1 |    3 |  118274 |  119119 |  118833
 master   |           2 |    3 |  152803 |  159090 |  156005
 master   |           4 |    3 |  174381 |  182288 |  177351
 master   |           8 |    3 |  115021 |  118117 |  116597
 master   |          16 |    3 |   39048 |   43935 |   40835
 master   |          32 |    3 |   35754 |   40716 |   37940
 master   |          64 |    3 |   33417 |   36906 |   35495
 master   |         128 |    3 |   37925 |   42433 |   40193
 patch-v1 |           1 |    3 |  118589 |  119503 |  118902
 patch-v1 |           2 |    3 |  194204 |  195457 |  194873
 patch-v1 |           4 |    3 |  189771 |  192332 |  190672
 patch-v1 |           8 |    3 |  123929 |  125904 |  124793
 patch-v1 |          16 |    3 |  112328 |  114584 |  113312
 patch-v1 |          32 |    3 |  107975 |  108949 |  108469
 patch-v1 |          64 |    3 |  104649 |  105275 |  104994
 patch-v1 |         128 |    3 |   99792 |  100479 |  100246
(16 rows)

/Joel