Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 4270057

Browse files
committed
Remove obsolete comment about VACUUM retrying pruning
Commit 1ccc1e0 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
1 parent f1bb928 commit 4270057

File tree

1 file changed

+2
-6
lines changed

1 file changed

+2
-6
lines changed

src/backend/access/heap/pruneheap.c

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

0 commit comments

Comments
 (0)