| 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:23:41 |
| Message-ID: | E1ws5Yz-00000000TrL-2XSP@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
------
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(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2026-08-06 21:29:55 | pgsql: Restore vacuum failsafe abandonment of buffer access strategy |
| Previous Message | Nathan Bossart | 2026-08-06 18:10:41 | pgsql: Remove lo_hton64() and lo_ntoh64(). |