Re: HOT chain validation in verify_heapam() - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: HOT chain validation in verify_heapam()
Date
Msg-id CAH2-Wz=MNzDu5ZsK7ctpr1RcBoU_kHKaL6pC4qGVUM6EYkfUSA@mail.gmail.com
Whole thread Raw
In response to Re: HOT chain validation in verify_heapam()  (Andres Freund <andres@anarazel.de>)
Responses Re: HOT chain validation in verify_heapam()
List pgsql-hackers
On Mon, Nov 14, 2022 at 9:38 AM Andres Freund <andres@anarazel.de> wrote:
> Anyway, I played a bit around with this. It's hard to hit, not because we
> somehow won't choose such a horizon, but because we'll commonly prune the
> earlier tuple version away due to xmax being old enough.

That must be a bug, then. Since, as I said, I can't see how it could
possibly be okay to freeze an xmin of tuple in a HOT chain without
also making sure that it has no earlier versions left behind. If there
are earlier versions that we have to go through to get to the
frozen-xmin tuple (not just an LP_REDIRECT), we're going to break the
HOT chain traversal logic in code like heap_hot_search_buffer in a
rather obvious way.

HOT chain traversal logic code will interpret the frozen xmin from the
tuple as FrozenTransactionId (not as its raw xmin). So traversal is
just broken in this scenario.

> It *is* possible to
> hit, if the horizon increases between the two tuple version checks (e.g. if
> there's another tuple inbetween that we check the visibility of).

I suppose that that's the detail that "protects" us, then -- that
would explain the apparent lack of problems in the field. Your
sequence requires 3 sessions, not just 2.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Next
From: Aleksander Alekseev
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15