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.  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: pgsql: SQL-standard function body
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: pgsql: SQL-standard function body