From 2f38628373ccfb6e8f8fd883955056030092569d Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Thu, 28 Mar 2024 00:16:09 +0200 Subject: [PATCH v8 21/22] Add comment about a pre-existing issue Not sure if we want to keep this, but I wanted to document it for discussion at least. --- src/backend/access/heap/pruneheap.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c index e37ba655a7d..2b720ab6aa1 100644 --- a/src/backend/access/heap/pruneheap.c +++ b/src/backend/access/heap/pruneheap.c @@ -792,6 +792,23 @@ heap_prune_chain(Buffer buffer, OffsetNumber rootoffnum, * Note that we might first arrive at a dead heap-only tuple * either here or while following a chain below. Whichever path * gets there first will mark the tuple unused. + * + * FIXME: The next paragraph isn't new with these patches, but + * just something I realized while looking at this. But maybe we should + * add a comment like this? Or is it too much detail? + * + * Whether we arrive at the dead HOT tuple first here or while + * following a chain below affects whether preceding RECENTLY_DEAD + * tuples in the chain can be removed or not. Imagine that you + * have a chain with two tuples: RECENTLY_DEAD -> DEAD. If we + * reach the RECENTLY_DEAD tuple first, the chain-following logic + * will find the DEAD tuple and conclude that both tuples are in + * fact dead and can be removed. But if we reach the DEAD tuple + * at the end of the chain first, when we reach the RECENTLY_DEAD + * tuple later, we will not follow the chain because the DEAD + * TUPLE is already 'marked', and will not remove the + * RECENTLY_DEAD tuple. This is not a correctness issue, and the + * RECENTLY_DEAD tuple will be removed by a later VACUUM. */ if (!HeapTupleHeaderIsHotUpdated(htup)) { -- 2.39.2