Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-16 Thread Tom Lane
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

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-16 Thread Andreas Seltenreich
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

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Tom Lane
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

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Tom Lane
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 >

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Tom Lane
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

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-12 Thread Andreas Seltenreich
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

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-11 Thread Tom Lane
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

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-11 Thread Emre Hasegeli
> 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

[HACKERS] GiST index build versus NaN coordinates

2016-07-11 Thread Tom Lane
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