Commit4270057

committed

Remove obsolete comment about VACUUM retrying pruning

Commit1ccc1e0 removed the retry logic that the comment talkedabout.Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>Discussion:https://www.postgresql.org/message-id/20240328015326.x5gnzsohl6j23b42@liskov

1 parentf1bb928 commit4270057Copy full SHA for 4270057

File tree

-6

lines changed

-6

lines changed

Lines changed: 2 additions & 6 deletions

Original file line number	Diff line number	Diff line change
`@@ -435,12 +435,8 @@ heap_prune_satisfies_vacuum(PruneState *prstate, HeapTuple tup, Buffer buffer)`
`435`	`435`	`* This is OK because a RECENTLY_DEAD tuple preceding a DEAD tuple is really`
`436`	`436`	`* DEAD, our visibility test is just too coarse to detect it.`
`437`	`437`	`*`
`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.`
`444`	`440`	`*`
`445`	`441`	`* The root line pointer is redirected to the tuple immediately after the`
`446`	`442`	`* latest DEAD tuple. If all tuples in the chain are DEAD, the root line`

Comments

(0)