MIME-Version: 1.0
References: 
 <CALdSSPgZWX_D8+Fx4YQqRN5eW5iSx_rJdqQhCfdWTvqKXVfJ4w@mail.gmail.com>
 <CALdSSPgPs=gKWkKN0=4yBd49FBY=ijxBz4YGV64vfVMK7YQhpw@mail.gmail.com>
 <CALdSSPiaQptrccvRoHhP3=YqN9-K8duXfLHHm3G=+7FVL8A-Xw@mail.gmail.com>
 <CALdSSPh-QtT8NrhtKsNWwFVF3D4KX6Wy3qs-FPc16c6VAECEyg@mail.gmail.com>
 <CALdSSPgfFWUBc8RoOZe5PmoUGa4LJUDeMTcAT8HwXGCMGJ9uBA@mail.gmail.com>
 <449DFC8A-CF54-493E-9366-AF9C73C782AA@yandex-team.ru>
 <CALdSSPiGnqgvpfQDCydBf-=0hzyUs6Y0o0xNvd53BbcMWTVO=w@mail.gmail.com>
 <14B4E29D-7B08-4972-BE9E-491A8A6A77CF@yandex-team.ru>
 <CAMtXxw_=fD6hAoLPagLT8fEPa6qe=oD-6ecXq2h1UmtBLv_GFA@mail.gmail.com>
 <CALdSSPirzFew+O0ZVDh81f8m_cwd7SMdRMZwGa-uy7zg078dGQ@mail.gmail.com>
In-Reply-To: 
 <CALdSSPirzFew+O0ZVDh81f8m_cwd7SMdRMZwGa-uy7zg078dGQ@mail.gmail.com>
From: Soumya S Murali <soumyamurali.work@gmail.com>
Date: Fri, 20 Mar 2026 11:47:04 +0530
Message-ID: 
 <CAMtXxw_s2BVCABt_LHcvOy92f=FA1ewat+m32OmkWd64VJ95PQ@mail.gmail.com>
Subject: Re: Fix gistkillitems & add regression test to microvacuum
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
	Andres Freund <andres@anarazel.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAMtXxw_s2BVCABt_LHcvOy92f%3DFA1ewat%2Bm32OmkWd64VJ95PQ%40mail.gmail.com>
Precedence: bulk

Hi all,

On Wed, Mar 18, 2026 at 11:12=E2=80=AFAM Kirill Reshke <reshkekirill@gmail.=
com> wrote:
>
> On Wed, 11 Feb 2026 at 17:18, Soumya S Murali
> <soumyamurali.work@gmail.com> wrote:
> >
> > Hi all,
> >
> > 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...
>
> [0] https://git.postgresql.org/cgit/postgresql.git/commit/?id=3Df5eb854ab=
6d6281ec2d3143657944bdda6676341
>

I performed a follow-up test on top of the v3 patch with a strictly
controlled setup to ensure a single-page GiST index (confirming that
block 1 is out of range). To force the cleanup path, I executed an
index-only scan after deleting all tuples and used a narrow WAL window
to isolate the relevant records. The WAL output shows GiST PAGE_UPDATE
on block 0, confirming that the root page is modified after the scan.
However even in this setup, I do not observe any XLOG_GIST_DELETE
records. This seems while the patch correctly initializes curBlkno and
enables proper handling of the root page, the DELETE WAL emission
depends on whether killitems actually marks tuples as DEAD under the
given visible conditions.
Overall, the fix looks correct from a code perspective, but in this
scenario the cleanup does not result in a DELETE WAL record.

Regards,
Soumya