Horton

Re: pread() and pwrite()

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Jesper Pedersen <jesper.pedersen@redhat.com>, Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, Oskari Saarenmaa <os@ohmu.fi>, Pg Hackers <pgsql-hackers@postgresql.org>, Tobias Oberstein <tobias.oberstein@gmail.com>
Date: 2018-11-05T15:59:18Z
Lists: pgsql-hackers 
On 2018-Nov-04, Thomas Munro wrote:

> Here's a patch to add Windows support by supplying
> src/backend/port/win32/pread.c.  Thoughts?

Hmm, so how easy is to detect that somebody runs read/write on fds where
pread/pwrite have occurred?  I guess for data files it's easy to detect
since you'd quickly end up with corrupted files, but what about other
kinds of files?  I wonder if we should be worrying about using this
interface somewhere other than fd.c and forgetting about the limitation.
Say, what happens if we patch some place in xlog.c after this patch gets
in, using write() instead of pwrite()?

I suppose the safest approach is to use lseek (or whatever) to fix up
the position after the pread/pwrite -- but we don't want to pay the
price on an additional syscall.  Are there any other options?  Is there
a way to prevent read/write from being used on a file handle?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.