On Tue, Aug 14, 2012 at 5:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Noah Misch <noah@leadboat.com> writes:
>> On Tue, Aug 14, 2012 at 08:40:06AM -0400, Robert Haas wrote:
>>> On Tue, Aug 14, 2012 at 6:50 AM, Greg Stark <stark@mit.edu> wrote:
>>>> It is possible to check if the signal was synchronous or was sent from
>>>> an external process. You can check siginfo->si_pid to see who sent you
>>>> the signal. I'm not sure checking that and handling it at
>>>> check_for_interrupts if it's asynchronous is the best solution or not
>>>> though.
>
>>> If that's portable it might be an option, but I doubt that it is.
>
>> I suspect it is portable.
>
> Single Unix Spec V2 says (on the sigaction man page)
>
> The si_code member contains a code identifying the cause of the
> signal. If the value of si_code is less than or equal to 0, then the
> signal was generated by a process and si_pid and si_uid respectively
> indicate the process ID and the real user ID of the sender.
>
> I'm not sure I would trust checking si_pid alone; it would definitely
> fail on my old HPUX box, where I see that field is union'ed with si_addr
> and so will read as garbage for a locally-sourced SIGFPE. But it might
> be that checking si_code alone would work reliably.
>
> I think that rejecting an externally sourced SIGFPE might be worth doing
> if we can distinguish that reliably.
Currently, our signal handlers on all platforms are declared to take
just an int. We'd need to change that in order to try to do this.
Any thoughts on how we could go about that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company