On Wed, Feb 12, 2025 at 1:03 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2025-02-11 13:12:17 +1300, Thomas Munro wrote:
> > I was also
> > anticipating future code that would need to multiply that number by other
> > terms to allocate shared memory, but after some off-list discussion, that
> > seems OK: such code should be able to deal with that using GUCs instead of
> > maximally pessimal allocation. 128 gives a nice round number of 1M as a
> > maximum transfer size, and comparable systems seem to have upper limits
> > around that mark. Patch attached.
>
> To make that possible we'd need two different io_combine_limit GUCs, one
> PGC_POSTMASTER that defines a hard max, and one that can be changed at
> runtime, up to the PGC_POSTMASTER one.
>
> It's somewhat painful to have such GUCs, because we don't have real
> infrastructure for interdependent GUCs. Typically the easiest way is to just
> do a Min() at runtime between the two GUCs. But looking at the number of
> references to io_combine_limit in read_stream.c, that doesn't look like fun.
>
> Do you have a good idea how to keep read_stream.c readable?
How about just maintaining it in a new variable
effective_io_combine_limit, whenever either of them is assigned? You
don't get a friendly error message if you set the user-changeable one
too high, but the relationship between them can at least be clearly
documented. Something like this... (I didn't update the name in lots
of comments because it would reflow all the text...).