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

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: kehan5800(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19700: PostgreSQL: an SP-GiST index on `inet` makes IPv6 rows invisible
Date: 2026-09-22 06:15:50
Message-ID: F0540CC4-8A12-4636-896E-55691E408276@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 21 Sep 2026, Kirill Reshke wrote:
> 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.

I would keep the allTheSame test. There is a direct precedent in
btree_index.sql [0], which explicitly says that a test only provides
useful coverage with the default 8K BLCKSZ.

The recent GIN incomplete-split test [1] also needs a particular physical
layout, but compares index and sequential scan results rather than
hard-coding a layout-dependent row count.

I'd be more concerned about platform-dependent failures on the buildfarm
than about losing coverage with a different page layout. Here the
expected counts are always 290 and 1, regardless of alignment or where
the split happens. Could we verify that it fails with only the picksplit
fix applied, and passes with the complete fix?

Thank you!

Best regards, Andrey Borodin.

[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ec986020decff322723cf7b3a2696803d082ad17
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f20c4278342f6afc44b856e98a0850f9dd2df0a8

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2026-09-22 10:12:35 BUG #19712: MultiXact Recovery Deadlock
Previous Message Alexandre Felipe 2026-09-22 04:34:57 Re: BUG #19708: Hash Join becomes about 300x slower with higher work_mem