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

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