Date: Tue, 6 Feb 2024 20:39:41 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, noah@leadboat.com
Subject: Re: common signal handler protection
Message-ID: <20240207023941.GA67817@nathanxps13>
References: <20231121212008.GA3742740@nathanxps13>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231121212008.GA3742740@nathanxps13>
Archived-At: 
 <https://www.postgresql.org/message-id/20240207023941.GA67817%40nathanxps13>
Precedence: bulk

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