From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_preadv() and pg_pwritev()
Date: Sat, 19 Dec 2020 18:34:17 -0500
Message-ID: <341497.1608420857@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKGJA+u-220VONeoREBXJ9P3S94Y7J+kqCnTYmahvZJwM=g@mail.gmail.com>
References: <CA+hUKGJA+u-220VONeoREBXJ9P3S94Y7J+kqCnTYmahvZJwM=g@mail.gmail.com>
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:
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.
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.
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?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com
Subject: Re: pg_preadv() and pg_pwritev()
In-Reply-To: <341497.1608420857@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox