On Sat, Apr 26, 2025 at 5:43 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: > > It's kinda sad to not have any test that tests a larger > > io_combine_limit/io_max_combine_limit - as evidenced by this bug that'd be > > good. However, not all platforms have PG_IOV_MAX > 16, so it seems like it'd > > be somewhat painful to test? > > Maybe just skip the test if the maximum value of the GUC isn't > high enough?
We could also change IOV_MAX and thus PG_IOV_MAX to (say) 32 on Windows, if it's useful for testing. It's not real, I just made that number up when writing pwritev/preadv replacements, and POSIX says that 16 is the minimum a system should support. I have patches lined up to add real vectored I/O for Windows, and then the number will change anyway, probably harmonizing so that it works out to 1MB everywhere in practice. If it's useful to change it now for a test then I don't know any reason why not. The idea of the maximally conservative 16 was not to encourage people to set it to high numbers while it's emulated, but it's not especially important. Unixen have converged on IOV_MAX == 1024, most decades ago. I think AIX might be a hold-out, but we don't currently care about that, and Solaris only moved 16->1024 recently. If we change the fake numbers made up for Windows, say 16->32, then I suspect that would leave just one single machine in the 'farm that would skip the test if I understood the proposal correctly: margay, a Solaris box not receiving OS updates and thus missing "SRU72". Sorry for screwing up the GUC, it looks like I completely goofed on the contract for GUC assign functions! They aren't in charge of assigning, they're just called *on* assignment. Whoops. And thanks for fixing it.
