Incorrect result of bitmap heap scan.

Hi hackers,

Attached script reproduces the problem with incorrect results of `select
count(*)` (it returns larger number of records than really available in
the table).
It is not always reproduced, so you may need to repeat it multiple times
- at my system it failed 3 times from 10.

The problem takes place with pg16/17/18 (other versions I have not checked).

The test is called `test_ios` (index-only-scan), but it is not correct.
Index-only scan is not used in this case.
And this is actually the first question to PG17/18: IOS is not used when
number of records is less than 100k (for this particular table):

postgres=# create table t(pk integer primary key); CREATE TABLE
postgres=# set enable_seqscan = off; SET postgres=# set enable_indexscan
= off; SET postgres=# insert into t values (generate_series(1,1000));
INSERT 0 1000 postgres=# vacuum t; VACUUM postgres=# explain select
count(*) from t; QUERY PLAN
-------------------------------------------------------------------------------
Aggregate (cost=43.02..43.03 rows=1 width=8) -> Bitmap Heap Scan on t
(cost=25.52..40.52 rows=1000 width=0) -> Bitmap Index Scan on t_pkey
(cost=0.00..25.27 rows=1000 width=0) (3 rows) postgres=# set
enable_bitmapscan = off; SET postgres=# explain select count(*) from t;
QUERY PLAN ------------------------------------------------------------
Aggregate (cost=17.50..17.51 rows=1 width=8) -> Seq Scan on t
(cost=0.00..15.00 rows=1000 width=0) Disabled: true (3 rows)

So, as you can see, Postgres prefers to use disabled seqscan, but not
IOS. It is different from pg16 where disabling bitmap scan makes
optimizer to choose index-only scan:

postgres=# explain select count(*) from t; QUERY PLAN
----------------------------------------------------------- Aggregate
(cost=41.88..41.88 rows=1 width=8) -> Seq Scan on t (cost=0.00..35.50
rows=2550 width=0) (2 rows) postgres=# set enable_seqscan = off; SET
postgres=# explain select count(*) from t; QUERY PLAN
-------------------------------------------------------------------------------
Aggregate (cost=75.54..75.55 rows=1 width=8) -> Bitmap Heap Scan on t
(cost=33.67..69.17 rows=2550 width=0) -> Bitmap Index Scan on t_pkey
(cost=0.00..33.03 rows=2550 width=0) (3 rows) postgres=# set
enable_bitmapscan = off; SET postgres=# explain select count(*) from t;
QUERY PLAN
-------------------------------------------------------------------------------
Aggregate (cost=45.77..45.78 rows=1 width=8) -> Index Only Scan using
t_pkey on t (cost=0.28..43.27 rows=1000 width=0) (2 rows)

This is strange behavior of pg17 which for some reasons rejects IOS (but
it is used if number of records in the table is 100k or more). But the
main problem is that used plan Bitmap Heap Scan + Bitmap Index Scan may
return incorrect result.

Replacing `select count(*)` with `select count(pk)` eliminates the
problem, as well as disabling of autovacuum. It seems to be clear that
the problem is with visibility map.

We have the following code in heap bitmap scan: /* * We can skip
fetching the heap page if we don't need any fields from the * heap, the
bitmap entries don't need rechecking, and all tuples on the * page are
visible to our transaction. */ if (!(scan->rs_flags & SO_NEED_TUPLES) &&
!tbmres->recheck && VM_ALL_VISIBLE(scan->rs_rd, tbmres->blockno,
&hscan->rs_vmbuffer)) { /* can't be lossy in the skip_fetch case */
Assert(tbmres->ntuples >= 0); Assert(hscan->rs_empty_tuples_pending >=
0); hscan->rs_empty_tuples_pending += tbmres->ntuples; return true; }

So if we do not need tuples (|count(*)|case) and page is marked as
all-visible in VM, then we just count|tbmres->ntuples|elements without
extra checks.
I almost not so familiar with internals of executor, but it is not clear
to me how we avoid race condition between VM update and heap bitmap scan?

Assume that bitmap scan index marks all tids available in index. Some
elements in this bitmap can refer old (invisible) versions. Then vacuum
comes, removes dead elements and mark page as all-visible. After it we
start heap bitmap scan, see that page is all-visible and count all
marked elements on this page including dead (which are not present in
the page any more).
Which lock or check should prevent such scenario?