Andreas Seltenreich writes:
> I wrote:
>> Sounds like some fuzz testing with nan/infinity is in order.
> related fallout: close_ps returns a NULL pointer with NaNs around:
> select close_ps('(nan,nan)', '(nan,nan),(nan,nan)');
> -- TRAP: FailedAssertion("!(result != ((void *)0))", File: "geo_ops.
I wrote:
> Sounds like some fuzz testing with nan/infinity is in order.
related fallout: close_ps returns a NULL pointer with NaNs around:
select close_ps('(nan,nan)', '(nan,nan),(nan,nan)');
-- TRAP: FailedAssertion("!(result != ((void *)0))", File: "geo_ops.c", Line:
2860)
regards,
Andreas
I wrote:
> Andreas Seltenreich writes:
>> The infinite loop from the bug report was triggered. Further, two
>> previously unseen errors are logged:
>> ERROR: timestamp cannot be NaN
>> ERROR: getQuadrant: impossible case
>> The first is porbably as boring as it gets, the second one is from the
>
I wrote:
> I looked into the problem reported in bug #14238,
> https://www.postgresql.org/message-id/20160708151747.1426.60...@wrigleys.postgresql.org
> I think that probably the most reasonable answer is to replace all the
> raw "double" comparisons in this code with float8_cmp_internal() or
> som
Andreas Seltenreich writes:
> Tom Lane writes:
>> More generally, this example makes me fearful that NaN coordinates in
>> geometric values are likely to cause all sorts of issues. It's too late
>> to disallow them, probably, but I wonder how can we identify other bugs
>> of this ilk.
> Sounds l
Tom Lane writes:
> More generally, this example makes me fearful that NaN coordinates in
> geometric values are likely to cause all sorts of issues. It's too late
> to disallow them, probably, but I wonder how can we identify other bugs
> of this ilk.
Sounds like some fuzz testing with nan/infin
Emre Hasegeli writes:
>> I think that probably the most reasonable answer is to replace all the
>> raw "double" comparisons in this code with float8_cmp_internal() or
>> something that's the moral equivalent of that. Does anyone want to
>> propose something else?
> We can probably get away by ch
> I think that probably the most reasonable answer is to replace all the
> raw "double" comparisons in this code with float8_cmp_internal() or
> something that's the moral equivalent of that. Does anyone want to
> propose something else?
We can probably get away by changing the comparison on the
I looked into the problem reported in bug #14238,
https://www.postgresql.org/message-id/20160708151747.1426.60...@wrigleys.postgresql.org
The submitter was kind enough to give me a copy of the problem data,
and it turns out that the issue is that a few of the boxes contain
NaN coordinates. Armed w
