Re: SIGFPE handler is naive

On Mon, Aug 13, 2012 at 01:04:58PM -0400, Robert Haas wrote:
> A member of our technical team brought it to my attention that if you
> have a recalcitrant backend that doesn't die when you send it a
> SIGTERM, and you don't want to cause a crash-and-restart cycle by
> sending it SIGQUIT, you can have your cake and eat it too by sending
> it SIGFPE, which will cheerfully throw an error from wherever inside
> the backend you happen to be, whether it is safe or not. I suppose we
> had it in mind when this was coded that SIGFPE would only be generated
> by the system rather than by user activity, and it is a pretty neat
> trick for working around the lack of CHECK_FOR_INTERRUPTS() in some
> place where you really wish there were one, but the possibility of
> setting yourself on fire also seems rather high. Since the person who
> made the discovery realized the utility of the trick but not the fact
> that it might destabilize the backend, it seems that the surface area
> for self-destruction is non-zero.
>
> Should we do something to plug this, and if so, what? If not, should
> we document the danger?

If this use of SIGFPE is handy, we should expose it under a better name. What
hazards make it unsafe? In a critical section, it escalates to a PANIC
anyway. In third-party library code, the library state may become corrupt.
In backend code skipping a PG_TRY/PG_CATCH for sections that "cannot" throw
errors, cleanup will never happen. That's plenty of danger, but I can
sympathize with folks wanting to take the risk and use SIGFPE this way.

Overall, though, I think it best to plug this. We could set a flag before
each operation, like evaluation of SQL arithmetic, for which SIGFPE is normal.
If the signal handler sees the flag set, raise ERROR. Otherwise, PANIC. Code
running with the flag set would, of course, need to be ready for a spontaneous
elog(ERROR) at any instruction.

Thanks,
nm