From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, glyn(at)8kb(dot)co(dot)uk |
Subject: | Opossum vs. float4 NaN |
Date: | 2019-01-26 16:00:05 |
Message-ID: | 24767.1548518405@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I see that opossum's owner just resurrected it after a period of being
MIA ... and it's failing a few regression tests with symptoms like
this:
SELECT 'NaN'::float4;
- float4
---------
- NaN
+ float4
+----------
+ Infinity
(1 row)
I have no doubt that this is caused by the same platform bug that
I worked around in commit cb3e9e40b:
However, it emerges that this tickles a compiler or hardware bug on
buildfarm member opossum. Test results from commit 55e0e4581 show
conclusively that widening a float4 NaN to float8 produces Inf, not NaN,
on that machine; which accounts perfectly for the window RANGE test
failures it's been showing. We can dodge this problem by making
in_range_float4_float8 be an independent function, so that it checks
for NaN inputs before widening them.
The reason that it's reappeared is the refactoring we've done recently
around snprintf: float4out is now taking its float4 argument and widening
it to double to pass to strtod, which is where the checks for Inf/NaN
happen.
We could imagine band-aiding around this by adding something like
#if defined(__netbsd) && defined(__mips)
if (isnan(num))
// return "NaN"
#endif
to float4out, but ick. I was willing to do cb3e9e40b because it didn't
really make the code any uglier, but this would. And I bet the issue
is going to cause problems somewhere for Andrew's Ryu patch, too.
I'm thinking we should regretfully retire opossum, unless there's
a software update available for it that fixes this bug.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2019-01-26 16:16:07 | Re: Opossum vs. float4 NaN |
Previous Message | Tom Lane | 2019-01-26 15:44:44 | Re: Use zero for nullness estimates of system attributes |