MIME-Version: 1.0
References: 
 <CAAKRu_Z8Ry_ynNBPAzs_Ry3MQi9NaBgt1ccLgwRsDbxWpocaBg@mail.gmail.com>
 <CAAKRu_ZhHtEaucO--SdYrCjq0zgqk_LPztUD+-QS74A2htXgKw@mail.gmail.com>
 <CAAKRu_Zj8G4T=HN3QSY7iQvkKSQk-k1fq+eJkjCBNqoSg63z+Q@mail.gmail.com>
 <CAAKRu_bgP-DMZs=D2j2N0+U9+uWU5cVagw-yZLOuhYbWj_KwnA@mail.gmail.com>
 <itvgqc6vncbjsjfmrptfvkkeg5vqzhalaguya2z77t6c6ctpc3@wsdrgbn4bxaa>
 <CAAKRu_aWMyGB=zg5W7+RUtor6TqsiOwHXSL7Dg4TUUiTSzzcpw@mail.gmail.com>
 <2be31f17-5405-4de9-8d73-90ebc322f7d8@vondra.me>
 <CAAKRu_Ypa7-JGVR+fstDxU5Cfitk_rf5ijdaqwtoPkztursufA@mail.gmail.com>
 <CAAKRu_ZrDadxmGepBwPZ03yAKnMxwsHYn8SK9Gg7VqigLLVUWg@mail.gmail.com>
 <CAApHDvqAOeOwCKh9g0gfxWa040=Hyc7_oA=C59rjod8kXJDWyw@mail.gmail.com>
 <CAAKRu_Yt76_HdfR6DtK_wtkSNSj9=VxSV_npt+6T2R=zTzp1Pg@mail.gmail.com>
 <CAAKRu_atv6zA274m8Ysgbfn49c0NbdvHT7nXvd9kroZKnFq8Dg@mail.gmail.com>
 <CAApHDvq_R-gNXu+06GQW6w_HaEMh1pezsyiCh7GNhgh+h0UqMw@mail.gmail.com>
 <CAAKRu_YfoGTHNn0XxA+dCPj9hyO96vO4Eb+awRR6T8m22qC6ww@mail.gmail.com>
 <97529f5a-ec10-46b1-ab50-4653126c6889@gmail.com>
In-Reply-To: <97529f5a-ec10-46b1-ab50-4653126c6889@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Sun, 5 Apr 2026 11:42:19 -0400
Message-ID: 
 <CAAKRu_b=X-P26hB96i2vG40PhJB_5L=ARuNHV4SJngMPap8H3A@mail.gmail.com>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas@vondra.me>,
	David Rowley <dgrowleyml@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>,
	Chao Li <li.evan.chao@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>,
	Xuneng Zhou <xunengzhou@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAAKRu_b%3DX-P26hB96i2vG40PhJB_5L%3DARuNHV4SJngMPap8H3A%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 3, 2026 at 1:00=E2=80=AFAM Alexander Lakhin <exclusion@gmail.co=
m> wrote:
>
> I've come across an interesting failure produced starting from 378a21618:
> when using a build made with CFLAGS=3D"-DRELCACHE_FORCE_RELEASE" and
> echo "io_method =3D sync" >/tmp/temp.config, the test run:
> TEMP_CONFIG=3D/tmp/temp.config TESTS=3Dtemp make -s check-tests
>
> fails as below:
> --- .../src/test/regress/expected/temp.out   2026-02-13 06:15:55.88736862=
4 +0200
> +++ .../src/test/regress/results/temp.out    2026-04-03 07:51:36.73550415=
6 +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