Re: BUG #19700: PostgreSQL: an SP-GiST index on `inet` makes IPv6 rows invisible

On Mon, 21 Sept 2026 at 14:29, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> On 21 Sep 2026, Kirill Reshke wrote:
> > So, I updated inet_spg_choose to support the 'allTheSame' case.
>
> The code changes look correct. Could the new comment explain that
> checkAllTheSame() can exclude the incoming tuple? Here picksplit did
> separate the families, but the remaining old tuples all went to one
> node. The file header also needs an exception to its claim that a
> prefixless tuple has exactly two family-specific nodes.

> Could we add regression coverage for both the original missing-rows case
> and this insertion case, checking searches for both families afterwards?
> The latter is a separate bug and should fail even with just the
> picksplit fix applied. It would be useful to cover IPv4 arriving after
> IPv6 duplicates too.

Added regression test. It exercises indexscan part of issue. another
test that is useful here is when we split allTheSame page with
different family inet class:

+CREATE TABLE inet_tbl_allthesame (i inet);
+CREATE INDEX inet_idx_allthesame ON inet_tbl_allthesame USING spgist (i);
+INSERT INTO inet_tbl_allthesame SELECT '10.0.0.1' FROM generate_series(1, 290);
+INSERT INTO inet_tbl_allthesame VALUES ('8000::1');
+SELECT count(*) FROM inet_tbl_allthesame WHERE i = '10.0.0.1';
+SELECT count(*) FROM inet_tbl_allthesame WHERE i = '8000::1';
+DROP TABLE inet_tbl_allthesame;

But this is dependent on page size and does not actually check that
things go bad or not. So I did not include this in v2.

> In inner_consistent, checking allTheSame first would let both cases use
> the existing visit-all-nodes branch.
>
> I'd also suggest to add the reporter's REINDEX warning into the commit
> message. And few words of what is going on would be helpful too.

ok

--
Best regards,
Kirill Reshke