Hi, On 2025-03-22 22:00:00 +0200, Alexander Lakhin wrote: > 15.03.2025 16:43, Melanie Plageman wrote: > > On Thu, Mar 13, 2025 at 5:41 PM Melanie Plageman > > <melanieplage...@gmail.com> wrote: > > > Overall, I feel pretty good about merging this once Thomas merges the > > > read stream patches. > > This was committed in 944e81bf99db2b5b70b, 2b73a8cd33b745c, and > > c3953226a07527a1e2. > > I've marked it as committed in the CF app. > > It looks like that change made the bitmapops test unstable (on slow > animals?): [1], [2], [3]. > I've reproduced such test failures when running > TESTS=$(printf 'bitmapops %.0s' `seq 50`) make -s check-tests > under Valgrind: > ... > ok 17 - bitmapops 52719 ms > not ok 18 - bitmapops 57566 ms > ok 19 - bitmapops 60179 ms > ok 20 - bitmapops 32927 ms > ok 21 - bitmapops 45127 ms > ok 22 - bitmapops 42924 ms > ok 23 - bitmapops 61035 ms > ok 24 - bitmapops 56316 ms > ok 25 - bitmapops 52874 ms > not ok 26 - bitmapops 67468 ms > ok 27 - bitmapops 55605 ms > ok 28 - bitmapops 24021 ms > ... > > diff -U3 /home/vagrant/postgresql/src/test/regress/expected/bitmapops.out > /home/vagrant/postgresql/src/test/regress/results/bitmapops.out > --- /home/vagrant/postgresql/src/test/regress/expected/bitmapops.out > 2025-03-16 01:37:52.716885600 -0700 > +++ /home/vagrant/postgresql/src/test/regress/results/bitmapops.out > 2025-03-22 03:47:54.014702406 -0700 > @@ -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. Greetings, Andres Freund
