diff options
| author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2024-03-28 10:18:48 +0200 |
|---|---|---|
| committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2024-03-28 10:18:48 +0200 |
| commit | 427005742bd2efdcee0f361e17d1a76664ff001b (patch) | |
| tree | fb8516afdfb51eb419162688c48b138837764c43 | |
| parent | f1bb9284f73437b3f2011dad5e815c8738758aef (diff) | |
| download | postgresql-427005742bd2efdcee0f361e17d1a76664ff001b.tar.gz postgresql-427005742bd2efdcee0f361e17d1a76664ff001b.zip | |
Remove obsolete comment about VACUUM retrying pruning
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
| -rw-r--r-- | src/backend/access/heap/pruneheap.c | 8 |
1 files changed, 2 insertions, 6 deletions
diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c index 4e58c2c2ff4..ef816c2fa9c 100644 --- 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 |