mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove obsolete comment about VACUUM retrying pruning

Browse Source 
Commit 1ccc1e05ae removed the retry logic that the comment talked
about.

Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>
Discussion: https://www.postgresql.org/message-id/20240328015326.x5gnzsohl6j23b42@liskov
This commit is contained in:
Heikki Linnakangas 2024-03-28 10:18:48 +02:00
parent f1bb9284f7
commit 427005742b
1 changed files with 2 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/backend/access/heap/pruneheap.c
View File

@ -435,12 +435,8 @@ heap_prune_satisfies_vacuum(PruneState *prstate, HeapTuple tup, Buffer buffer)
* This is OK because a RECENTLY_DEAD tuple preceding a DEAD tuple is really * This is OK because a RECENTLY_DEAD tuple preceding a DEAD tuple is really
* DEAD, our visibility test is just too coarse to detect it. * DEAD, our visibility test is just too coarse to detect it.
* *
* In general, pruning must never leave behind a DEAD tuple that still has * Pruning must never leave behind a DEAD tuple that still has tuple storage.
* tuple storage. VACUUM isn't prepared to deal with that case. That's why * VACUUM isn't prepared to deal with that case.
* VACUUM prunes the same heap page a second time (without dropping its lock
* in the interim) when it sees a newly DEAD tuple that we initially saw as
* in-progress. Retrying pruning like this can only happen when an inserting
* transaction concurrently aborts.
* *
* The root line pointer is redirected to the tuple immediately after the * The root line pointer is redirected to the tuple immediately after the
* latest DEAD tuple. If all tuples in the chain are DEAD, the root line * latest DEAD tuple. If all tuples in the chain are DEAD, the root line