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

On 22 Sep 2026, Kirill Reshke wrote:
> Yes, but for HEAD it's OK and will be an idiomatic way to fix.

I found two false negatives with v2, on fresh indexes.

1. A BRIN range containing just one non-NULL NaN box never calls
box_mergeable(). brin_inclusion_add_value() copies the first value and
returns at "if (new)", leaving INCLUSION_UNMERGEABLE false:

CREATE TABLE b (v box);
INSERT INTO b VALUES ('(NaN,NaN),(0,0)');
CREATE INDEX bi ON b USING brin (v);
SET enable_seqscan = off;
SELECT * FROM b WHERE v ~= box '(NaN,NaN),(0,0)';

This returns no rows, versus one with a seq scan. Adding a finite box
to the range makes the NaN row findable. We need to cover the initial
value too, not just merges.

2. GiST still loses the NaN row for the same equality predicate. With
1000 finite boxes and one NaN box, I get one row via seq scan and none
via GiST. rtree_internal_consistent() implements RTSameStrategyNumber
using box_contain(), which rejects a NaN query even when the stored
bound is infinite.

Thank you!

Best regards, Andrey Borodin.