Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

On Fri, Apr 3, 2026 at 1:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> I've come across an interesting failure produced starting from 378a21618:
> when using a build made with CFLAGS="-DRELCACHE_FORCE_RELEASE" and
> echo "io_method = sync" >/tmp/temp.config, the test run:
> TEMP_CONFIG=/tmp/temp.config TESTS=temp make -s check-tests
>
> fails as below:
> --- .../src/test/regress/expected/temp.out 2026-02-13 06:15:55.887368624 +0200
> +++ .../src/test/regress/results/temp.out 2026-04-03 07:51:36.735504156 +0300
> @@ -493,11 +493,7 @@
>
> -- Check that read streams deal with lower number of pins available
> SELECT count(*), max(a) max_a, min(a) min_a, max(cnt) max_cnt FROM test_temp;
> - count | max_a | min_a | max_cnt
> --------+-------+-------+---------
> - 10000 | 10000 | 1 | 0
> -(1 row)
> -
> +ERROR: no empty local buffer available
> ROLLBACK;

It has to do with the query needing an additional pin for the VM
during on-access pruning and the read stream reading ahead until there
is only one remaining buffer pin in the local pin limit (the cursor
above is already consuming much of the backend local pin limit). We
could perhaps fix this test by decreasing the pages in the relation or
increasing the backend local pin limit, but I wonder if we need to do
something more invasive to ensure that we can pin at least two
buffers.

FWIW, I don't think this can be hit with the FSM, because we release
the heap buffer pin before pinning it. Though perhaps there are other
places in the code where scanning a single buffer with the read stream
entails pinning at least one other buffer.

- Melanie