Re: BUG #19524: NaN handling in btree_gist's float4/float8 opclasses

Thanks.
v2 applies cleanly on master and contrib/btree_gist regression passes here.
Nothing to add.

regards,
Bill

2026년 6월 30일 (화) 오전 8:08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>님이 작성:

> I studied this and decided that it only partially fixes the problem.
> Yes, we've got to fix the comparison functions, but we also have to
> fix the penalty and distance functions. As things stand, the penalty
> functions will probably return NaN for any input including a NaN,
> which gistpenalty will clamp to zero, which we do not want because
> it'll basically break all decisions about where to put things,
> leading to a seriously inefficient index. (Maybe gistpenalty should
> do something else with a NaN, but I'm hesitant to touch that right
> now.) The penalty logic is also under the misapprehension that
> multiplying everything by 0.49 keeps it from having to worry about
> overflows; that won't fix things for infinities. The distance
> functions will do the wrong things for NaN as well, probably breaking
> any KNN search that happens across a NaN index entry.
>
> So I fixed all that, and then was dismayed to find that the new
> penalty logic wasn't reached at all in the regression tests, per code
> coverage testing. We don't compute any penalties during GiST index
> build unless it's a multicolumn index, so most of the per-datatype
> tests aren't reaching that. It didn't seem like adding more index
> entries partway through the test would fit very well into the
> structure of float[48].sql, so instead I added simple tests of
> two-column float indexes to improve the coverage. Also, I thought
> we should test this logic by adding NaN (and infinities for good
> measure) to the initial data load, rather than creating a new small
> table which would only exercise the logic very minimally.
>
> At the moment I'm leaning to back-patching this. We'd have to
> release-note the need to reindex any btree_gist indexes containing
> NaNs, but we've done similar things many times before.
>
> regards, tom lane
>
>