| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Allow signal handlers to optionally use SA_SIGINFO information? |
| Date: | 2014-11-10 18:05:46 |
| Message-ID: | 20141110180546.GE28007@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-11-10 09:50:17 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-11-10 18:15:07 | Re: Proposal: Log inability to lock pages during vacuum |
| Previous Message | Jim Nasby | 2014-11-10 18:03:59 | Re: Proposal: Log inability to lock pages during vacuum |