Horton

Re: HOT chain validation in verify_heapam()

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: pgsql-hackers@lists.postgresql.org, Himanshu Upadhyaya <upadhyaya.himanshu@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-11-14T22:58:10Z
Lists: pgsql-hackers 
Hi,

On 2022-11-14 14:42:16 -0800, Peter Geoghegan wrote:
> What does this have to tell us, if anything, about the implications
> for code on HEAD?

Nothing really test I sent (*) - I wanted to advance the discussion about the
patch being wrong as-is in a concrete way.

This logic was one of my main complaints in
https://postgr.es/m/20221109220803.t25sosmfvkeglhy4%40awork3.anarazel.de
and you went in a very different direction in your reply. Hence a test
showcasing the issue.

Note that neither of my complaints around FrozenTransactionId in that email
actually require that HOT is involved. The code in the patch doesn't
differentiate between hot and not-hot until later.


> I don't see any connection between this problem and the possibility of a
> live bug on HEAD involving freezing later tuple versions in a HOT chain,
> leaving earlier non-frozen versions behind to break HOT chain traversal
> code. Should I have noticed such a connection?

No.

Greetings,

Andres Freund

(*) the commented out test perhaps is an argument for expanding the comment
nd "We will advance past RECENTLY_DEAD tuples just in case there's a DEAD
after them;" in heap_prune_chain()

Commits

  1. amcheck: Generalize one of the recently-added update chain checks.

  2. amcheck: Tighten up validation of redirect line pointers.

  3. amcheck: Fix verify_heapam for tuples where xmin or xmax is 0.

  4. amcheck: Fix a few bugs in new update chain validation.

  5. Fix new test case to work on (some?) big-endian architectures.

  6. Don't test HEAP_XMAX_INVALID when freezing xmax.