Hi all,
Thank you for the updated patch.
On Wed, Feb 11, 2026 at 2:52 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>
> > On 23 Jan 2026, at 16:03, Kirill Reshke <reshkekirill@gmail.com> wrote:
> >
> > On Tue, 20 Jan 2026 at 15:30, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> >>
> >>
> >>
> >>> On 15 Jan 2026, at 22:59, Kirill Reshke <reshkekirill@gmail.com> wrote:
> >>>
> >>> PFA v2 which leaves the test in-place.
> >>>
> >>> Also commit message improvements.
> >>
> >> Yeah, killtuples for GiST root page is broken. Your patch is fixing it.
> >> I don't think we should backpatch this, the bug is harmless, but for master the patch LGTM.
> >
> > Thank you
> >
> >> It would be good to assign so->curBlkno and so->curBlkno together. But gistScanPage() is the only place with
accessto the block number.
> >
> > Sorry, didnt get this take.
>
> Sorry, I meant so->curBlkno and so->numKilled are semantically correlated. But it's difficult to assign them together
andthis does not worth refactoring.
>
> >
> >> +# Test gist, but with fewer rows - that killitems used to be buggy.
> >>
> >> Probably, in this comment we can explicitly say that killitems was buggy, but now is fixed.
> >>
> >
> > Hmm, what would be a good wording here?
>
> I've opened an English dictionary and it says "used to" can be used with a meaning "bug was there but it's not
anymore".
>
> So the patch is RfC IMO.
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.
Thanks,
Soumya
