Re: pread() and pwrite()

From: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Oskari Saarenmaa <os(at)ohmu(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Tobias Oberstein <tobias(dot)oberstein(at)gmail(dot)com>
Subject: Re: pread() and pwrite()
Date: 2018-11-06 15:41:58
Message-ID: 856530e2-260d-1d61-ec18-595778868a1b@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 11/5/18 9:10 PM, Thomas Munro wrote:
> On Tue, Nov 6, 2018 at 5:07 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> Please remove Tell from line 18 in fd.h. To Küssnacht with him!
>
> Thanks, done. But what is this arrow sticking through my Mac laptop's
> screen...?
>
> On Tue, Nov 6, 2018 at 6:23 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>>> 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.
>>
>> Yeah. I think the patch as presented is OK; it uses pread/pwrite only
>> inside fd.c, which is a reasonably non-leaky abstraction. But there's
>> definitely a hazard of somebody submitting a patch that depends on
>> using pread/pwrite elsewhere, and then that maybe not working.
>>
>> What I suggest is that we *not* try to make this a completely transparent
>> substitute. Instead, make the functions exported by src/port/ be
>> "pg_pread" and "pg_pwrite", and inside fd.c we'd write something like
>>
>> #ifdef HAVE_PREAD
>> #define pg_pread pread
>> #endif
>>
>> and then refer to pg_pread/pg_pwrite in the body of that file. That
>> way, if someone refers to pread and expects standard functionality
>> from it, they'll get a failure on platforms not supporting it.
>
> OK. But since we're using this from both fd.c and xlog.c, I put that
> into src/include/port.h.
>
>> FWIW, I tested the given patches on HPUX 10.20; they compiled cleanly
>> and pass the core regression tests.
>

Passes check-world, and includes the feedback on this thread.

New status: Ready for Committer

Best regards,
Jesper

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-11-06 15:48:36 Re: jsonpath
Previous Message Pavel Raiskup 2018-11-06 15:41:16 Re: plruby: rb_iterate symbol clash with libruby.so