Re: gistkillitems can LP_DEAD-mark the wrong tuples on a rescan

On Sun, Aug 16, 2026 at 8:24 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> Calling gistkillitems() from gistrescan() and gistendscan() looks like the
> right fix.

Attached patch does it that way. I'm not planning on committing my
original isolation test.

In the back branches, we should add hardening that defensively resets
numKilled on a rescan. This hardening might not be necessary, but
including it is easier than proving we don't need it. I've attached a
second very simple patch showing how I plan to do this on the
backbranches.

I'll commit these patches in the next couple of days, barring any
objections. For release management purposes these patches will be
treated as a single item.

> Longer term, I think the block number, page LSN and
> killed offsets should form one kill-state object, initialized only for a
> leaf page and invalidated as a unit. Visiting an internal page should never
> replace the identity of the page to which pending kill offsets belong.

The ongoing amgetbatch work (which enables index prefetching) forces
index AMs to do things that way: the equivalent of gistkillitems is
passed a batch that describes the items returned to the core executor
from a given leaf page earlier on. This batch data structure contains
a deadItems[] array that indicates which specific tuples from that
same page should be LP_DEAD-marked now. These dead item arrays are
tied to and accessed through one particular batch, so there's almost
no way for an index AM to misuse it; the index AM's opaque state
doesn't need to be kept in sync with the batch information passed
through by the core executor.

--
Peter Geoghegan