Re: pgsql: Use SIGURG rather than SIGUSR1 for latches. - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Use SIGURG rather than SIGUSR1 for latches.
Date
Msg-id 4006115.1618577212@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Use SIGURG rather than SIGUSR1 for latches.  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: pgsql: Use SIGURG rather than SIGUSR1 for latches.
List pgsql-committers
Thomas Munro <thomas.munro@gmail.com> writes:
> Here's a patch to change that.  But... on second thoughts, and after
> coming up with a commit message to explain the change, I'm not 100%
> convinced it's worth committing.  You can't get SIGURG without
> explicitly asking for it (by setting maybe_sleeping), which makes it a
> bit more like SIGALRM than SIGUSR2.  I don't feel very strongly about
> this though.  What do you think?

Hmm, yeah, after looking more closely at InitializeLatchSupport I agree.
There's so much platform variability in whether we use the signal handler
at all that it seems best to keep it SIGIGN'd until we reach that code.

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".

Is it really necessary to mess with UnBlockSig?

            regards, tom lane



pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pgsql: SQL-standard function body
Next
From: Laurenz Albe
Date:
Subject: Re: pgsql: SQL-standard function body