Re: pread() and pwrite()

Thomas Munro <thomas.munro@enterprisedb.com>

From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Pg Hackers <pgsql-hackers@postgresql.org>, Oskari Saarenmaa <os@ohmu.fi>, Tobias Oberstein <tobias.oberstein@gmail.com>
Date: 2018-09-02T03:04:20Z
Lists: pgsql-hackers
On Sat, Jul 21, 2018 at 3:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > No objections, if you want to make the effort. But IMHO the lseek+read
> > fallback is good enough on Windows. Unless you were thinking that we
> > could then remove the !HAVE_PREAD fallback altogether. Are there any
> > other platforms out there that don't have pread/pwrite that we care about?
>
> AFAICT, macOS has them as far back as we care about (prairiedog does).
> HPUX 10.20 (gaur/pademelon) does not, so personally I'd like to keep
> the lseek+read workaround.  Don't know about the oldest Solaris critters
> we have in the buildfarm.  FreeBSD has had 'em at least since 4.0 (1994);
> didn't check the other BSDen.
>
> SUS v2 (POSIX 1997) does specify both functions, so we could insist on
> their presence without breaking any of our own portability guidelines.
> However, if we have to have some workaround anyway for Windows, it
> seems like including an lseek+read code path is reasonable so that we
> needn't retire those oldest buildfarm critters.

Yeah it seems useful and cheap to carry the lseek() fallback.  But
actually there is a good reason to implement proper pread/pwrite
(equivalent) on Windows: this patch removes the position tracking, so
that the fallback code generates *more* lseek() calls than current
master.  For example with sequential reads today we are smart enough
to skip redundant lseek() calls, but this patch removes those smarts.
I doubt anyone cares about that on HPUX 10.20 but I don't think we
should do that on Windows.

-- 
Thomas Munro
http://www.enterprisedb.com


Commits

  1. Use pg_pread() and pg_pwrite() for data files and WAL.

  2. Provide pg_pread() and pg_pwrite() for random I/O.

  3. Convert some long lists in configure.in to one-line-per-entry style.