Re: BUG #19705: One NaN box makes a BRIN box_inclusion_ops index omit unrelated rows

On Wed, 23 Sept 2026 at 08:43, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Andrey,
> > I found two false negatives with v2, on fresh indexes.
>
> Thanks, I reproduced both. v3 attached. 0001 is Kirill's v2 unchanged,
> 0002 fixes your cases, with tests that fail without it.
>
> 1. BRIN now asks the mergeable function about the first value too, by
> merging it with itself. No change for inet.
>
> 2. GiST internal pages no longer prune ~= when the query has a NaN.
> There is nothing safe to compare it with.
>
> 0002 also stops gist_box_union() from copying a NaN first entry.
>
> Thanks,
> Shihao
>

Cool, thanks for v3.

I think that addition to brin_inclusion_add_value is correct but looks
like we need the same guard for brin_inclusion_consistent?

Also, maybe it is worth making two patches here, one for BRIN and
other for GiST for sake of simplicity.

I also think that we can avoid rebuilding indexes after fix here, only
lose selectivity on the poisoned subtrees. Looks like an internal key
carrying a NaN should match every strategy. So, we can place new
tuples with NaN -> inf substitution, while making tree search recurse
in whole subtree in case of old (NaN) value.
Does it sound?

Also, we can make the master BRIN patch to not touch boxes_bound_box()
at al. Only INCLUSION_UNMERGEABLE is sufficient.

--
Best regards,
Kirill Reshke