On Fri, Feb 15, 2019 at 5:29 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Thomas Munro <thomas.munro@xxxxxxxxxxxxxxxx> writes: > >> On Fri, Feb 15, 2019 at 2:56 PM Bruce Klein <brucek@xxxxxxxxx> 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
