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
> > <melanieplageman@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
