On Sun, Dec 20, 2020 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > I want to be able to do synchronous vectored file I/O, so I made
> > wrapper macros for preadv() and pwritev() with fallbacks for systems
> > that don't have them. Following the precedent of the pg_pread() and
> > pg_pwrite() macros, the "pg_" prefix reflects a subtle contract
> > change: the fallback paths might have the side effect of changing the
> > file position.
>
> In a quick look, seems OK with some nits:
Thanks for looking!
> 1. port.h cannot assume that <limits.h> has already been included;
> nor do I want to fix that by including <limits.h> there. Do we
> really need to define a fallback value of IOV_MAX? If so,
> maybe the answer is to put the replacement struct iovec and
> IOV_MAX in some new header.
Ok, I moved all this stuff into port/pg_uio.h.
> 2. I'm not really that happy about loading <sys/uio.h> into
> every compilation we do, which would be another reason for a
> new specialized header that either includes <sys/uio.h> or
> provides fallback definitions.
Ack.
> 3. The patch as given won't prove anything except that the code
> compiles. Is it worth fixing at least one code path to make
> use of pg_preadv and pg_pwritev, so we can make sure this code
> is tested before there's layers of other new code on top?
OK, here's a patch to zero-fill fresh WAL segments with pwritev().
I'm drawing a blank on trivial candidate uses for preadv(), without
infrastructure from later patches.