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: Sun, 20 Dec 2020 02:07:24 -0500
Message-ID: <359768.1608448044@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKG+7UHOH2VGRwvJZ=vXUH9pRA-Tp3gP9EHgtjwzjyfOpWg@mail.gmail.com>
References: <CA+hUKGJA+u-220VONeoREBXJ9P3S94Y7J+kqCnTYmahvZJwM=g@mail.gmail.com>
<341497.1608420857@sss.pgh.pa.us>
<CA+hUKG+7UHOH2VGRwvJZ=vXUH9pRA-Tp3gP9EHgtjwzjyfOpWg@mail.gmail.com>
Thomas Munro <thomas.munro@gmail.com> writes:
> 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.
This looks OK to me. I tried it on prairiedog (has writev and
pwrite but not pwritev) as well as gaur (has only writev).
They seem happy.
One minor thought is that in
+ struct iovec iov[Min(IOV_MAX, 1024)]; /* cap stack space */
it seems like pretty much every use of IOV_MAX would want some
similar cap. Should we centralize that idea with, say,
#define PG_IOV_MAX Min(IOV_MAX, 1024)
? Or will the plausible cap vary across uses?
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: <359768.1608448044@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