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:43:34 +0000 (15:43 +1300)
commit75da2bece670059f3c1a3628dfbc3d24cc9638b8
tree85b0766df59540ecadd94781d46c7547221e2f16
parentd4f79865d4207bd93fa00f521638c289f036e276
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