agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: Melanie Plageman <melanieplageman@gmail.com>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: Restore vacuum failsafe abandonment of buffer access strategy
Date: Thu, 06 Aug 2026 21:23:41 +0000
Message-ID: <E1ws5Yz-00000000TrL-2XSP@gemulon.postgresql.org> (raw)
Restore vacuum failsafe abandonment of buffer access strategy
VACUUM's wraparound failsafe mode exists to reclaim transaction IDs as
quickly as possible. 4830f1024325 made the failsafe stop using the
BAS_VACUUM buffer access strategy so that the rest of the vacuum could
make use of all of shared buffers rather than being confined to the
small strategy ring.
However, when 9256822608f3 made vacuum's first heap pass use the read
stream, this was accidentally disabled. The read stream keeps its own
references to the buffer access strategy, so clearing vacrel->bstrategy
in lazy_check_wraparound_failsafe() no longer had any effect on the
reads issued by the first pass.
Fix this by adding clearing the BufferAccessStrategy reference actually
being used by the ongoing scan -- those in the ReadBuffersOperations
structs themselves.
Two things we accept rather than fix, as neither is worth the added
complexity given how rarely failsafe mode is reached:
- A small amount of read time for IOs that were already in progress when
the strategy was cleared may be attributed to IOCONTEXT_NORMAL instead
of IOCONTEXT_VACUUM. WaitReadBuffers() derives the IOContext from the
(now cleared) strategy, so the wait time of these in-flight IOs is
misattributed. This is bounded by the stream's look-ahead window and
happens at most once per vacuum, when the strategy is first cleared.
- The stream's buffer pin limit stays lower than it would have been had
no strategy been used at all. max_pinned_buffers is capped by the
strategy's pin limit when the stream is created and is not recomputed
when the strategy is cleared. Raising it would mean building a new,
larger ring, which would require first waiting for all in-progress IOs
to complete. That didn't seem worth it.
Reported-by: Jingtang Zhang <mrdrivingduck@gmail.com>
Discussion: https://postgr.es/m/CAPsk3_APRYVLhAJ5TMwdmpSx8W_%3DPHMm%3DPmKAvnC3gBrfNommQ%40mail.gmail.com
Backpatch-to: 18
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/112c2683807b4d690a19e0a182246b219832b1d0
Modified Files
--------------
src/backend/access/heap/vacuumlazy.c | 25 ++++++++++++++++++++++---
src/backend/storage/aio/read_stream.c | 21 +++++++++++++++++++++
src/include/storage/read_stream.h | 1 +
3 files changed, 44 insertions(+), 3 deletions(-)
view thread (3+ messages) latest in thread
Message-ID: <E1ws5Yz-00000000TrL-2XSP@gemulon.postgresql.org>
Permalink: ../E1ws5Yz-00000000TrL-2XSP@gemulon.postgresql.org/
Also on: postgresql.org/message-id/E1ws5Yz-00000000TrL-2XSP@gemulon.postgresql.org
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: melanieplageman@gmail.com, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Restore vacuum failsafe abandonment of buffer access strategy
In-Reply-To: <E1ws5Yz-00000000TrL-2XSP@gemulon.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox