Hi, On 2025-03-22 16:14:11 -0400, Andres Freund wrote: > On 2025-03-22 22:00:00 +0200, Alexander Lakhin wrote: > > @@ -24,14 +24,14 @@ > > SELECT count(*) FROM bmscantest WHERE a = 1 AND b = 1; > > count > > ------- > > - 23 > > + 18 > > (1 row) > > Is it possible that this is the bug reported here: > https://postgr.es/m/873c33c5-ef9e-41f6-80b2-2f5e11869f1c%40garret.ru > > I.e. that the all-visible logic in bitmap heapscans is fundamentally broken? > > I can reproduce different results on a fast machien by just putting a VACUUM > FREEZE bmscantest after the CREATE INDEXes in bitmapops.sql. After I disable > the all-visible logic in bitmapheap_stream_read_next(), I can't observe such a > difference anymore.
Hm, it's clearly related to the all-visible path, but I think the bug is actually independent of what was reported there. The bug you reported is perfectly reproducible, without any concurrency, after all. Here's a smaller reproducer: CREATE TABLE bmscantest (a int, t text); INSERT INTO bmscantest SELECT (r%53), 'foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo' FROM generate_series(1,70000) r; CREATE INDEX i_bmtest_a ON bmscantest(a); set enable_indexscan=false; set enable_seqscan=false; -- Lower work_mem to trigger use of lossy bitmaps set work_mem = 64; SELECT count(*) FROM bmscantest WHERE a = 1; vacuum freeze bmscantest; SELECT count(*) FROM bmscantest WHERE a = 1; -- clean up DROP TABLE bmscantest; The first SELECT reports 1321, the second 572 tuples. Greetings, Andres Freund
