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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Use SIGURG rather than SIGUSR1 for latches.
Date: 2021-04-16 12:46:52
Message-ID: 4006115.1618577212@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Laurenz Albe 2021-04-16 14:09:12 Re: pgsql: SQL-standard function body
Previous Message Peter Eisentraut 2021-04-16 10:26:16 Re: pgsql: SQL-standard function body