On Sun, Aug 16, 2026 at 8:24 AM Andrey Borodin <[email protected]> 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
0001-Backpatch.patch
Description: Binary data
v1-0001-GiST-Invalidate-killed-items-consistently.patch
Description: Binary data
