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
