git.postgresql.org Git - postgresql.git/commitdiff

git projects / postgresql.git / commitdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: f1bb928)
Remove obsolete comment about VACUUM retrying pruning
2024年3月28日 08:18:48 +0000 (10:18 +0200)
2024年3月28日 08:18:48 +0000 (10:18 +0200)
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


diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c
index 4e58c2c2ff4392c2ce556838b731d1b673aa0179..ef816c2fa9c947e07a3fac7d1bd3267f34f0143b 100644 (file)
--- a/src/backend/access/heap/pruneheap.c
+++ b/src/backend/access/heap/pruneheap.c
@@ -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
* DEAD, our visibility test is just too coarse to detect it.
*
- * In general, pruning must never leave behind a DEAD tuple that still has
- * tuple storage. VACUUM isn't prepared to deal with that case. That's why
- * 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.
+ * Pruning must never leave behind a DEAD tuple that still has tuple storage.
+ * VACUUM isn't prepared to deal with that case.
*
* 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
This is the main PostgreSQL git repository.
RSS Atom

AltStyle によって変換されたページ (->オリジナル) /