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()
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>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Sun, 20 Dec 2020 16:26:42 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <359767.1608448044.1@sss.pgh.pa.us>
Date: Sun, 20 Dec 2020 02:07:24 -0500
Message-ID: <359768.1608448044@sss.pgh.pa.us>
Precedence: bulk

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