Re: BitmapHeapScan streaming read user and prelim refactoring

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(at)gmail(dot)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