From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | andres(at)anarazel(dot)de, noah(at)leadboat(dot)com |
Subject: | Re: common signal handler protection |
Date: | 2024-02-07 02:39:41 |
Message-ID: | 20240207023941.GA67817@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 21, 2023 at 03:20:08PM -0600, Nathan Bossart wrote:
> * Overhead: The wrapper handler calls a function pointer and getpid(),
> which AFAICT is a real system call on most platforms. That might not be
> a tremendous amount of overhead, but it's not zero, either. I'm
> particularly worried about signal-heavy code like synchronous
> replication. (Are there other areas that should be tested?) If this is
> a concern, perhaps we could allow certain processes to opt out of this
> wrapper handler, provided we believe it is unlikely to fork or that the
> handler code is safe to run in grandchild processes.
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.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2024-02-07 02:48:53 | Re: common signal handler protection |
Previous Message | Yugo NAGATA | 2024-02-07 01:19:03 | Re: pgbnech: allow to cancel queries during benchmark |