Re: common signal handler protection

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: common signal handler protection
Дата
Msg-id 20240207170650.GA80671@nathanxps13
обсуждение исходный текст
Ответ на Re: common signal handler protection  (Andres Freund <andres@anarazel.de>)
Ответы Re: common signal handler protection  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On Tue, Feb 06, 2024 at 06:48:53PM -0800, Andres Freund wrote:
> On 2024-02-06 20:39:41 -0600, Nathan Bossart wrote:
>> I finally spent some time trying to measure this overhead.  Specifically, I
>> sent many, many SIGUSR2 signals to postmaster, which just uses
>> dummy_handler(), i.e., does nothing.  I was just barely able to get
>> wrapper_handler() to show up in the first page of 'perf top' in this
>> extreme case, which leads me to think that the overhead might not be a
>> problem.
> 
> That's what I'd expect. Signal delivery is fairly heavyweight, getpid() is one
> of the cheapest system calls (IIRC only beat by close() of an invalid FD on
> recent-ish linux).  If it were to become an issue, we'd much better spend our
> time reducing the millions of signals/sec that'd have to involve.

Indeed.

I'd like to get this committed (to HEAD only) in the next few weeks.  TBH
I'm not wild about the weird caveats (e.g., race conditions when pqsignal()
is called within a signal handler), but I also think it is unlikely that
they cause any issues in practice.  Please do let me know if you have any
concerns about this.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Christensen
Дата:
Сообщение: Constant Splitting/Refactoring
Следующее
От: "Euler Taveira"
Дата:
Сообщение: Re: Possibility to disable `ALTER SYSTEM`