From 8b93cbf472c2d4e3182a41e362b242d0b4d1b57d Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Tue, 20 Jun 2023 11:08:54 +1200
Subject: [PATCH v3 2/3] Fix race in SSI interaction with bitmap heap scan.

When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages.  Therefore, we can't skip
fetching any heap tuples that are referenced by the index, because we
need to test them all with CheckForSerializableConflictOut().  The
old optimization that would ignore any references to blocks >=
rs_nblocks gets in the way of that requirement, because it means that
concurrent writes in that window are ignored.

Removing that optimization shouldn't affect correctness at any isolation
level, because any new tuples shouldn't be visible to an MVCC snapshot.
There also shouldn't be any error-causing references to heap blocks past
the end, because we should have held at least an AccessShareLock on the
table before the index scan.  It can't get smaller while our transaction
is running.

Back-patch to all supported releases.  In release 11, the removed code
is in a different location due to the table AM refactoring in commit
bfbcad47, but not fundamentally different.

Reported-by: Artem Anisimov <artem.anisimov.255@gmail.com>
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org
---
 src/backend/access/heap/heapam_handler.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c
index 0755be8390..b41de7e3e1 100644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2128,15 +2128,6 @@ heapam_scan_bitmap_next_block(TableScanDesc scan,
 	hscan->rs_cindex = 0;
 	hscan->rs_ntuples = 0;
 
-	/*
-	 * Ignore any claimed entries past what we think is the end of the
-	 * relation. It may have been extended after the start of our scan (we
-	 * only hold an AccessShareLock, and it could be inserts from this
-	 * backend).
-	 */
-	if (block >= hscan->rs_nblocks)
-		return false;
-
 	/*
 	 * Acquire pin on the target heap page, trading in any pin we held before.
 	 */
-- 
2.40.1

