Re: Allow signal handlers to optionally use SA_SIGINFO information? - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Allow signal handlers to optionally use SA_SIGINFO information?
Date
Msg-id 5460A675.8050802@vmware.com
Whole thread Raw
In response to Allow signal handlers to optionally use SA_SIGINFO information?  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: group locking: incomplete patch, just for discussion
Next
From: Amit Kapila
Date:
Subject: Re: [v9.5] Custom Plan API