Fix read_stream.c for changing io_combine_limit.
authorThomas Munro <tmunro@postgresql.org>
Thu, 13 Mar 2025 02:43:34 +0000 (15:43 +1300)
committerThomas Munro <tmunro@postgresql.org>
Thu, 13 Mar 2025 02:48:02 +0000 (15:48 +1300)
commite273468070ab4212b0babb5b6e94cb57256c3512
tree3e6c9b309f43239b308189e94261f022b7e1ed28
parent8b2392ae3d5b7e1225ea5d7ffde1d65791dd112a
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
src/backend/storage/aio/read_stream.c