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