Re: PostgreSQL for VAX on NetBSD/OpenBSD

On 22 Aug 2015 18:02, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Why not define infnan() and make it do the same thing as
> FloatExceptionHandler? Or was that what you meant?

That's exactly what I meant, instead of my quick hack to add a signal
handler for sigill.

> > The hang is actually in the groupingset tests in
> > bipartite_match.c:hk_breadth_search().
...
> 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 think it never exits that function but I'll try it again.

> 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?

I didn't do anything. There's no isinf.o in that directory so I don't
think anything got compiled. There are other files in src/port but not
that.

> > 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?

Hmm. The backtrace is here but I think it's lying about the specific line.

#0 convert_one_string_to_scalar (value=0x7f20e9a3 " ",
rangelo=32, rangehi=122, 2132863395, 32, 122)
at selfuncs.c:3873
#1 0x00435880 in convert_string_to_scalar (
value=0x7f20e990 "Aztec\n", ' ' <repeats 11 times>, "Ct ",
scaledvalue=0x7fffdb44,
lobound=0x7f225bf4 "Audrey", ' ' <repeats 24 times>, "Dr ",
scaledlobound=0x7fffdb34,
hibound=0x7f225c40 "Balmoral", ' ' <repeats 22 times>, "Dr ",
scaledhibound=0x7fffdb3c, 2132863376, 2147474244, 2132958196,
2147474228, 2132958272, 2147474236) at selfuncs.c:3847

Stepping through the code it looks like it actually happens on line
3882 when denom overflows.

(gdb) n
3882 denom *= base;
3: denom = 1.666427615935998e+37
2: num = 0.37361810145459621
1: slen = 0

(gdb) n
Program received signal SIGFPE, Arithmetic exception.
convert_one_string_to_scalar (value=0x7f20e9a4 " ",
rangelo=32, rangehi=122, 2132863396, 32, 122)
at selfuncs.c:3873