| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, David Rowley <dgrowleyml(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
| Date: | 2026-04-05 15:49:15 |
| Message-ID: | yemtvnnnj4c6ehsmv6cu2x7h5i3nentpoeuqdtmyp3lnrw7ydu@7uwd2pogt5nv |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-04-05 11:42:19 -0400, Melanie Plageman wrote:
> 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.
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-04-05 15:50:11 | Re: Better shared data structure management and resizable shared data structures |
| Previous Message | Melanie Plageman | 2026-04-05 15:42:19 | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |