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

> I guess the OP is reporting about a .deb that was built on a real Linux
system

Yes, I (OP) installed via:
% wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc |
sudo apt-key add -
% sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/
$(lsb_release -sc)-pgdg main" > /etc/apt/sources.list.d/PostgreSQL.list'
% sudo apt update
% sudo apt-get install postgresql-11

> no one bothered to complain about PostgreSQL spewing scary looking
warnings on WSL for years

At least you weren't spamming a once-per-second(!) log entry about a
missing function call like one of my other packages did (can't remember,
maybe it was nginx?)

WSL still feels early and if you're going to try it, you get used to
annoyances like that. I'm glad Microsoft is trying though and I hope with
time and support they get all the way there because developers who have
enterprise or other reasons to be on Windows instead of Mac desktops
deserve to have decent unix tools too. Warts and all I still find it
overall more convenient and fluid than my previous VirtualBox / vagrant
solution.

On Fri, Feb 15, 2019 at 11:20 AM Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
wrote:

> On Sat, Feb 16, 2019 at 6:50 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On February 15, 2019 9:44:50 AM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >Andres Freund <andres(at)anarazel(dot)de> writes:
> > >> On February 15, 2019 9:13:10 AM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>