Re: PostgreSQL for VAX on NetBSD/OpenBSD - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PostgreSQL for VAX on NetBSD/OpenBSD
Date
Msg-id 20151.1440262944@sss.pgh.pa.us
Whole thread Raw
In response to Re: PostgreSQL for VAX on NetBSD/OpenBSD  (Greg Stark <stark@mit.edu>)
Responses Re: PostgreSQL for VAX on NetBSD/OpenBSD  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane <tgl@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: (full) Memory context dump considered harmful
Next
From: Tomas Vondra
Date:
Subject: Re: (full) Memory context dump considered harmful