Re: pgsql: Use SIGURG rather than SIGUSR1 for latches.
От | Tom Lane |
---|---|
Тема | Re: pgsql: Use SIGURG rather than SIGUSR1 for latches. |
Дата | |
Msg-id | 4006115.1618577212@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Use SIGURG rather than SIGUSR1 for latches. (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: pgsql: Use SIGURG rather than SIGUSR1 for latches.
|
Список | 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 по дате отправления: