Lowering temp_buffers minimum
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t51129psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 27, 2026 at 10:08 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t51129_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t51129_2 && git checkout t51129_2Patchset v2 (message #2) is on t51129_2
Hi,
I am working on writing some tests for temporary tables. One of the tests is
that we correctly handle running out of buffer pins. That's a bit more
annoying than it needs to because the minimum for temp_buffers is 100.
It seems rather odd that our minimum for temp_buffers is 100 while the minimum
for shared_buffers, which is shared across connections!, is 16.
Does anybody see a reason we shouldn't lower temp_buffers to match
shared_buffers?
Greetings,
Andres Freund
Hi,
On 2025-02-25 09:33:36 -0500, Andres Freund wrote:
I am working on writing some tests for temporary tables. One of the tests is
that we correctly handle running out of buffer pins. That's a bit more
annoying than it needs to because the minimum for temp_buffers is 100.It seems rather odd that our minimum for temp_buffers is 100 while the minimum
for shared_buffers, which is shared across connections!, is 16.Does anybody see a reason we shouldn't lower temp_buffers to match
shared_buffers?
FWIW, here's a set of patches adding some testing for temp table corner cases
that aren't currently hit, even in master. They work with temp_buffers = 100,
but would require a smaller table if a lower minimum . And indeed the test
would currently fail without the preceding commits I included, which are from
/messages/by-id/CA+hUKGK_=4CVmMHvsHjOVrK6t4F=LBpFzsrr3R+aJYN8kcTfWg@mail.gmail.com
Greetings,
Andres Freund
Attachments:
t51129_2v1-0001-Improve-buffer-pool-API-for-per-backend-pin-limit.patchtext/x-diff; charset=us-asciiDownload+77-19
v1-0002-Respect-pin-limits-accurately-in-read_stream.c.patchtext/x-diff; charset=us-asciiDownload+95-17
v1-0003-WIP-tests-Expand-temp-table-tests-to-some-pin-rel.patchtext/x-diff; charset=us-asciiDownload+264-2
On Tue, Feb 25, 2025 at 9:33 AM Andres Freund <andres@anarazel.de> wrote:
Does anybody see a reason we shouldn't lower temp_buffers to match
shared_buffers?
I do not see any such reason. I'd say go for it.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, 25 Feb 2025 at 15:33, Andres Freund <andres@anarazel.de> wrote:
It seems rather odd that our minimum for temp_buffers is 100 while the
minimum
for shared_buffers, which is shared across connections!, is 16.
Hmm, given that, I'd say we also increase that minimum shared_buffers to a
value >= 33 as the highest number of pages that can be addressed in one WAL
record: We allow users to write WAL records with 33 pages without pinning
the relevant buffers, but recovery doesn't do direct-to-disk options. So, I
think it's better to increase this limit.
Does anybody see a reason we shouldn't lower temp_buffers to match
shared_buffers?
None that I can think of. As Robert said, go for it.
Kind regards,
Matthias van de Meent
Neon (https://neon.tech)