Re: Issues with hash and GiST LP_DEAD setting for kill_prior_tuple - Mailing list pgsql-hackers

On Thu, Jul 17, 2025 at 7:27 PM Mihail Nikalayeu
<mihailnikalayeu@gmail.com> wrote:
> > FWIW _hash_readpage has a comment about a stashed LSN, so it seems as
> >  if this was barely missed by the work on hash indexes around 2017:
>
> I think commit 22c5e735 [0] (Remove lsn from HashScanPosData) is the
> thing you are looking for in relation to hash.

Oh yeah, good catch.

I wonder if this is already correct. It definitely *looks* wrong,
because _hash_kill_items() is prepared to re-pin and then LP_DEAD-mark
a page, without the LSN check that would make that safe. But it seems
possible that that never actually happens -- maybe the
HashScanPosIsPinned() check will invariably find that the page is
already pinned (in which case commit 22c5e735 merely neglected to
remove some dead code from _hash_kill_items, but was otherwise
correct).

Do you happen to recall anything about this, Robert and Amit?

FWIW, I'm asking about this now because I want to switch index AMs
that use amgettuple over to a new amgetbatch interface that enables
index prefetching, with prefetch windows that can span multiple leaf
pages. This involves moving management of buffer pins out of affected
index AMs, and into a new layer that will decide when to release each
index page buffer pin (and call _hash_kill_items-like routines) based
on its own criteria.

--
Peter Geoghegan