On Sat, May 18, 2024 at 6:23 PM Noah Misch <noah@leadboat.com> wrote:
>
> Are there obstacles to fixing the hang by back-patching 1ccc1e05ae instead of
> this? We'll need to get confident about 1ccc1e05ae before v17, and that
> sounds potentially easier than getting confident about both 1ccc1e05ae and
> this other approach.
I haven't tried back-patching 1ccc1e05ae yet, but I don't understand
why we would want to use stable back branches to get comfortable with
an approach committed to an unreleased version of Postgres.
The small fix proposed in this thread is extremely minimal and
straightforward. It seems much less risky as a backpatch.
> Regarding getting confident about 1ccc1e05ae, I think I
> follow the upthread arguments that it does operate correctly. As a cross
> check, I looked at each mention of oldestxmin in vacuumlazy.c and vacuum.c.
> Does the following heap_vacuum_rel() comment need an update?
>
> /*
> * Get cutoffs that determine which deleted tuples are considered DEAD,
> * not just RECENTLY_DEAD, and which XIDs/MXIDs to freeze. Then determine
> * the extent of the blocks that we'll scan in lazy_scan_heap. It has to
> * happen in this order to ensure that the OldestXmin cutoff field works
> * as an upper bound on the XIDs stored in the pages we'll actually scan
> * (NewRelfrozenXid tracking must never be allowed to miss unfrozen XIDs).
> *
> * Next acquire vistest, a related cutoff that's used in pruning. We
> * expect vistest will always make heap_page_prune_and_freeze() remove any
> * deleted tuple whose xmax is < OldestXmin.
Which part are you thinking needs an update? The part about vistest
always making heap_page_prune_and_freeze() remove any deleted tuples
whose xmax < OldestXmin?
- Melanie