From: | Thomas Munro <tmunro(at)postgresql(dot)org> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Fix read_stream.c for changing io_combine_limit. |
Date: | 2025-03-13 03:00:35 |
Message-ID: | E1tsYoF-002CS2-20@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Fix read_stream.c for changing io_combine_limit.
In a couple of places, read_stream.c assumed that io_combine_limit would
be stable during the lifetime of a stream. That is not true in at least
one unusual case: streams held by CURSORs where you could change the GUC
between FETCH commands, with unpredictable results.
Fix, by storing stream->io_combine_limit and referring only to that
after construction. This mirrors the treatment of the other important
setting {effective,maintenance}_io_concurrency, which is stored in
stream->max_ios.
One of the cases was the queue overflow space, which was sized for
io_combine_limit and could be overrun if the GUC was increased. Since
that coding was a little hard to follow, also introduce a variable for
better readability instead of open-coding the arithmetic. Doing so
revealed an off-by-one thinko while clamping max_pinned_buffers to
INT16_MAX, though that wasn't a live bug due to the current limits on
GUC values.
Back-patch to 17.
Discussion: https://postgr.es/m/CA%2BhUKG%2B2T9p-%2BzM6Eeou-RAJjTML6eit1qn26f9twznX59qtCA%40mail.gmail.com
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e273468070ab4212b0babb5b6e94cb57256c3512
Modified Files
--------------
src/backend/storage/aio/read_stream.c | 38 +++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 11 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-03-13 04:00:15 | pgsql: Avoid invalidating all RelationSyncCache entries on publication |
Previous Message | Thomas Munro | 2025-03-13 03:00:23 | pgsql: Fix read_stream.c for changing io_combine_limit. |