From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow signal handlers to optionally use SA_SIGINFO information? |
Date: | 2014-11-10 11:50:13 |
Message-ID: | 5460A675.8050802@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2014-11-10 11:55:58 | Re: [v9.5] Custom Plan API |
Previous Message | Amit Kapila | 2014-11-10 11:33:30 | Re: group locking: incomplete patch, just for discussion |