From 0f6aa893cb58c2a5a92016914c94865635345a22 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Tue, 31 Aug 2021 16:55:39 -0700 Subject: [PATCH] Remove obsolete nbtree relation extension comment. Commit 0d1fe9f7 improved the approach that vacuumlazy.c takes when it encounters an empty heap page. It no acquires the relation extension lock. --- src/backend/access/nbtree/nbtree.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/src/backend/access/nbtree/nbtree.c b/src/backend/access/nbtree/nbtree.c index be23395dfb..30df244703 100644 --- a/src/backend/access/nbtree/nbtree.c +++ b/src/backend/access/nbtree/nbtree.c @@ -963,11 +963,10 @@ btvacuumscan(IndexVacuumInfo *info, IndexBulkDeleteResult *stats, * recycled. Taking the lock synchronizes things enough to prevent a * problem: either num_pages won't include the new page, or _bt_getbuf * already has write lock on the buffer and it will be fully initialized - * before we can examine it. (See also vacuumlazy.c, which has the same - * issue.) Also, we need not worry if a page is added immediately after - * we look; the page splitting code already has write-lock on the left - * page before it adds a right page, so we must already have processed any - * tuples due to be moved into such a page. + * before we can examine it. Also, we need not worry if a page is added + * immediately after we look; the page splitting code already has + * write-lock on the left page before it adds a right page, so we must + * already have processed any tuples due to be moved into such a page. * * We can skip locking for new or temp relations, however, since no one * else could be accessing them.