Re: Fix gistkillitems & add regression test to microvacuum

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Soumya S Murali <soumyamurali(dot)work(at)gmail(dot)com>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Fix gistkillitems & add regression test to microvacuum
Date: 2026-07-07 18:22:15
Message-ID: d3c37744-c3b6-4c70-a8de-02aa23b486f9@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18/03/2026 07:42, Kirill Reshke wrote:
> On Wed, 11 Feb 2026 at 17:18, Soumya S Murali
> <soumyamurali(dot)work(at)gmail(dot)com> wrote:
>> Thank you for the updated patch.
>> I reproduced the issue locally by filling a GiST root page, deleting
>> all tuples, and triggering a microvacuum by an index-only scan.
>> With the patch, The root page is now handled consistently with other
>> leaf pages. so->curBlkno and so->curPageLSN are properly set during
>> scan, and gistkillitems() operates safely and correctly on the root
>> page.
>> Based on runtime validation and code inspection, the fix LGTM.
>
> Rebased due to f5eb854ab6d[0]
>
> I have added a [0]committer to CC.
>
> Andres, can you please take a look at this thread, if by chance you
> have spare time for it? You have changed kill tuples-related logic
> frequently, so you might be interested...

Looks good to me. It's natural to set curBlkNo in gistScanPage(),
because that's where curPageLSN is set too.

Committed, but I refrained from backpatching this for now, since it's a
pretty harmless bug. We could do that later if needed.

Thanks!

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2026-07-07 18:32:51 Re: TID recycling race during nbtree index-only scans that run on a standby
Previous Message Laurenz Albe 2026-07-07 18:16:36 Re: Adding a stored generated column without long-lived locks