On Fri, Apr 3, 2026 at 1:00 AM Alexander Lakhin <[email protected]> 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
