Thread: Allow signal handlers to optionally use SA_SIGINFO information?
Hi, During benchmarking/debugging I just had the problem that autovacuum was signalled at an insane rate - leading to more than one hundred autovac workers being started per second. Leading to a overall slowdown of more than 90% and the anti-wraparound vacuum not finishing. The problem is that I couldn't easily figure out where all the SIGUSR2's to the autovacuum launcher where coming from. This isn't the first time that I had that kind of problem. Posix provides information about the source of the signal when using SA_SIGINFO style handlers via si_code/si_pid. That information has been available for a *long* while (c.f. http://pubs.opengroup.org/onlinepubs/7908799/xsh/signal.h.html). I've now hacked up my development instance to log something like "autovacuum: invoked by pid 18175". I personally find that quite helpful. I can also imagine it being rather helpful to log information about the sender of SIGINT/TERM interrupts. The existing abstractions make are nearly sufficient to make it easy to optionally use SA_SIGINFO style handlers. Just by redifining SIGNAL_ARGS and pqsigfunc. There unfortunately is two things making it harder: SIG_IGN and SIG_DFL - those unfortunately can't be specified for SA_SIGINFO style handlers (as they have a different signature). So we'd need to use a different function for those two. Comments, ideas? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 11/10/2014 01:32 PM, Andres Freund wrote: > During benchmarking/debugging I just had the problem that autovacuum was > signalled at an insane rate - leading to more than one hundred autovac > workers being started per second. Leading to a overall slowdown of more > than 90% and the anti-wraparound vacuum not finishing. Ouch. > The problem is that I couldn't easily figure out where all the SIGUSR2's > to the autovacuum launcher where coming from. This isn't the first time > that I had that kind of problem. > > Posix provides information about the source of the signal when using > SA_SIGINFO style handlers via si_code/si_pid. That information has been > available for a *long* while > (c.f. http://pubs.opengroup.org/onlinepubs/7908799/xsh/signal.h.html). > > I've now hacked up my development instance to log something like > "autovacuum: invoked by pid 18175". I personally find that quite > helpful. I can also imagine it being rather helpful to log information > about the sender of SIGINT/TERM interrupts. > > The existing abstractions make are nearly sufficient to make it easy to > optionally use SA_SIGINFO style handlers. Just by redifining SIGNAL_ARGS > and pqsigfunc. There unfortunately is two things making it harder: > SIG_IGN and SIG_DFL - those unfortunately can't be specified for > SA_SIGINFO style handlers (as they have a different signature). So we'd > need to use a different function for those two. > > Comments, ideas? How about logging a line in the sender of the signal instead? - Heikki
Andres Freund <andres@2ndquadrant.com> writes: > Posix provides information about the source of the signal when using > SA_SIGINFO style handlers via si_code/si_pid. That information has been > available for a *long* while > (c.f. http://pubs.opengroup.org/onlinepubs/7908799/xsh/signal.h.html). That does not mean that it exists on all the platforms we support; Windows in particular is likely to be an issue. I concur with Heikki that you're probably solving this at the wrong end anyway, since the next question you'll be asking is *why* did process X send that signal. regards, tom lane
On 2014-11-10 09:50:17 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > Posix provides information about the source of the signal when using > > SA_SIGINFO style handlers via si_code/si_pid. That information has been > > available for a *long* while > > (c.f. http://pubs.opengroup.org/onlinepubs/7908799/xsh/signal.h.html). > > That does not mean that it exists on all the platforms we support; > Windows in particular is likely to be an issue. Given that we essentially use a named pipe to transport signals, it shouldn't be too hard if we decide we need it. > I concur with Heikki that you're probably solving this at the wrong > end anyway, since the next question you'll be asking is *why* did > process X send that signal. I agree that that's the most useful thing for any specific situation fully under our control. But generally I'd have more than once found it useful to have the sender of a signal available - even if it's just during debugging. I also previously would have liked to know where INT/TERM are coming from - having the senders pid can be useful to diagnose. If we add it, it's surely nothing we ever are going to rely on - as you say, there's portability issues. But printing it optionallY in a few place at appropriate debug levels + having it available in signal handlers during debugging sounds useful enough anyway to me. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services