>
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.munro@xxxxxxxxxxxxxxxx> wrote:
On Sat, Feb 16, 2019 at 6:50 AM Andres Freund <andres@xxxxxxxxxxx> wrote:
> On February 15, 2019 9:44:50 AM PST, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
> >Andres Freund <andres@xxxxxxxxxxx> writes:
> >> On February 15, 2019 9:13:10 AM PST, Tom Lane <tgl@xxxxxxxxxxxxx>
> >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
