Re: WSL (windows subsystem on linux) users will need to turn fsyncoff as of 11.2

On Sat, Feb 16, 2019 at 6:50 AM Andres Freund <andres@anarazel.de> wrote:
> On February 15, 2019 9:44:50 AM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >Andres Freund <andres@anarazel.de> writes:
> >> On February 15, 2019 9:13:10 AM PST, Tom Lane <tgl@sss.pgh.pa.us>
> >wrote:
> >>> I'm of the opinion that we shouldn't be panicking for
> >sync_file_range
> >>> failure, period.
> >
> >> With some flags it's strictly required, it does"eat"errors depending
> >on the flags. So I'm not sure I understand?
> >
> >Really?  The specification says that it starts I/O, not that it waits
> >around for any to finish.
>
> That depends on the flags you pass in. By memory I don't think it eats an error with our flags in recent kernels, but I'm not sure.

Right, there was some discussion of that, and I didn't (and still
don't) think it'd be wise to rely on undocumented knowledge about
which flags can eat errors based on a drive-by reading of a particular
snapshot of the Linux tree.  The man page says it can return EIO; I
think we should assume that it might actually do that.

BTW I had a report from someone on IRC that PostgreSQL breaks in other
ways (not yet understood) if you build it directly on WSL/Ubuntu.  I
guess the OP is reporting about a .deb that was built on a real Linux
system.  I'm vaguely familiar with these types of problems from other
platforms (Linux syscall emulation on FreeBSD and Sun-ish systems, and
also I'm old enough to remember people doing SCO SysV syscall
emulation on Linux systems back before certain valuable software was
available natively); it's possible that you get ENOSYS on other
emulators too, considering that other kernels don't seem to have a
sync_file_range()-like facility, but probably no one cares, since
there is no reason to run PostgreSQL on a syscall emulator when you
can run it natively.  This is a bit different though: I guess people
want to be able to develop Linux-stack stuff on company-issued Windows
computers for later deployment on Linux servers; someone interested in
this would ideally make it work and set up a build farm animal to tell
us when we break it.  It would probably require only minimal changes,
but considering that no one bothered to complain about PostgreSQL
spewing scary looking warnings on WSL for years, it's not too
surprising that we didn't consider this case before.  A bit like the
nightjar case, the PANIC patch revealed a pre-existing problem that
had gone unreported and needs some work, but it doesn't seem like a
very good reason to roll back that part of the change completely IMHO.

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