Re: PostgreSQL for VAX on NetBSD/OpenBSD

Greg Stark <stark(at)mit(dot)edu> writes:
> On 22 Aug 2015 18:02, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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 looked at that some more, and so far as I can see, its dependence on
Infinity, or really its use of float arithmetic at all, is a dumb-ass
idea. The distances are integers, and not very large ones either.
Which is fortunate, because if they did get large, you'd be having
problems with lost precision (ie, x+1 == x) somewhere around 2^24, long
before you got anywhere near exceeding the range of float or even int.
I think we should replace the whole mess with, say, uint32 for float and
UINT_MAX for infinity. That will be more portable, probably faster, and
it will work correctly up to substantially *larger* peak distances than
the existing code.

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

Some googling produced NetBSD man pages saying that isinf() and isnan()
are "not supported" on VAX. Given that your build is evidently finding
system-provided versions of them, it's a good bet that they are hard-wired
to produce 0. That would mean hk_breadth_search() necessarily returns
true, which would put its sole caller into an infinite loop. So quite
aside from VAX, this coding is utterly dependent on the assumption that
get_float4_infinity() produces something that isinf() will return true
for. I do not believe we have a hard dependency on that anywhere else.

regards, tom lane