pgsql: Restore vacuum failsafe abandonment of buffer access strategy

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Restore vacuum failsafe abandonment of buffer access strategy
Date: 2026-08-06 21:29:55
Message-ID: E1ws5f1-00000000TwA-23oL@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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(at)gmail(dot)com>
Discussion: https://postgr.es/m/CAPsk3_APRYVLhAJ5TMwdmpSx8W_%3DPHMm%3DPmKAvnC3gBrfNommQ%40mail.gmail.com
Backpatch-to: 18

Branch
------
REL_19_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/fd90c3221850d9ee1d05f4ce3f5420a54b3e471c

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(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-08-06 21:31:20 pgsql: Remove scram_client_key_len and scram_server_key_len from PGconn
Previous Message Melanie Plageman 2026-08-06 21:23:41 pgsql: Restore vacuum failsafe abandonment of buffer access strategy