Re: PostgreSQL for VAX on NetBSD/OpenBSD

Greg Stark <stark(at)mit(dot)edu> writes:
> On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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