Greg Stark <st...@mit.edu> writes: > On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> That seems worth poking into.
> Mea culpa. Not a planner crash but rather an overflow from exp(). It > turns out exp() and other math library functions on Vax do not signal > FPE but rather have a curious api that lets us catch the overflow by > defining a function "infnan()" to call when it overflows. If we don't > define that function then it executes an illegal instruction which > generates SIGILL with errno set to EDOM (iirc). For the moment I've > just attached our FPE handler to SIGILL and that's letting me run the > tests without crashes. It's probably just silly make-work but it would > be pretty easy to add a simple function to call our FPE handler > directly to avoid having to have a SIGILL handler which seems like a > bad idea in general. Why not define infnan() and make it do the same thing as FloatExceptionHandler? Or was that what you meant? > The hang is actually in the groupingset tests in > bipartite_match.c:hk_breadth_search(). > Looking at that function it's not surprising that it doesn't work > without IEEE floats given that the first line is > distance[0] = get_float4_infinity(); > And the return value of the function is > !isinf(distance[0]); Is it that function itself that's hanging, or is the problem that its caller expects it to ultimately return true, and it never does? I don't think we're really insisting on a true infinity here, only that get_float4_infinity() produce a large value that isinf() will recognize. I'm surprised that any of the hacks in src/port/isinf.c compile on Vax at all --- did you invent a new one? Also, I'd have thought that both get_floatX_infinity and get_floatX_nan would be liable to produce SIGFPE on non-IEEE machines. Did you mess with those? > The other place where non-IEEE floats are causing problems internal to > postgres appears to be inside spgist -- even when planning queries > using spgist: That's pretty odd --- it does not look like spgcostestimate does anything very exciting. Can you get a stack trace showing where that FPE happens? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers