Feedback-ID: id4a34324:Fastmail
Date: Sun, 5 Apr 2026 11:49:15 -0400
From: Andres Freund <andres@anarazel.de>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, 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>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
Message-ID: <yemtvnnnj4c6ehsmv6cu2x7h5i3nentpoeuqdtmyp3lnrw7ydu@7uwd2pogt5nv>
References: <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>
 <CAAKRu_b=X-P26hB96i2vG40PhJB_5L=ARuNHV4SJngMPap8H3A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAAKRu_b=X-P26hB96i2vG40PhJB_5L=ARuNHV4SJngMPap8H3A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/yemtvnnnj4c6ehsmv6cu2x7h5i3nentpoeuqdtmyp3lnrw7ydu%407uwd2pogt5nv>
Precedence: bulk

Hi,

On 2026-04-05 11:42:19 -0400, Melanie Plageman wrote:
> On Fri, Apr 3, 2026 at 1:00 AM Alexander Lakhin <exclusion@gmail.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.

I think we should probably just have GetLocalPinLimit() return something
considerably smaller than num_temp_buffers, e.g. num_temp_buffers / 4 or
so.

There always may be more than one scan going on, so we can't ever promise that
there's at least a certain number of pins available. The main goal of the
shared pin limit is to prevent one backend from pinning disproportionally much
of s_b.  And for that eventually scaling down to just needing 1-2 pins per
scan is sufficient.

Greetings,

Andres Freund