On Fri, Feb 15, 2019 at 5:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
> >> On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein <brucek@gmail.com> wrote:
> >>> In 11.1 did you see the message "WARNING: could not flush dirty data: Function not implemented"
> >> Yes
>
> > Here is a place where people go to complain about that:
> > https://github.com/Microsoft/WSL/issues/645
> > I suppose we could tolerate ENOSYS.
>
> What I'm not grasping here is why you considered that sync_file_range
> failure should be treated as a reason to PANIC in the first place?
> Surely it is not fsync(), nor some facsimile thereof. In fact, if
> any of the branches in pg_flush_data really need the data_sync_elevel
> treatment, somebody's mental model of that operation needs adjustment.
> Maybe it's mine.
My thinking was that sync_file_range() might in its current, future or
alternative (WSL, ...) implementation eat an error that would
otherwise reach fsync(), due to the single-flag error state treatment
we see in several OSes (older Linux, also recent Linux via the 'seen'
flag that we rely on to receive errors that happened before we opened
the fd). Should we be inspecting the Linux source or asking
assurances from Linux hackers that that can't happen? Perhaps it
behaves more like fdatasync() with the SYNC_FILE_RANGE_WAIT_* flags (=
can clear seen flag), but more like fadvise() without (can't touch
it)? I don't know, and I didn't want to base my choice on what it
looks like it currently does in the Linux tree. Without guarantees
from standards (not relevant here) or man pages (which note only that
EIO is possible), I made what I thought was an appropriately
pessimistic choice.
--
Thomas Munro
http://www.enterprisedb.com
