| 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
| 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 |