Hi, On 2024-02-06 20:39:41 -0600, Nathan Bossart wrote: > 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.
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. Greetings, Andres Freund