Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFS destination throws fsync error at end of backup
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: John Klann <jk7255@gmail.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-02-24T11:09:53Z
Lists: pgsql-bugs
On Sat, Feb 23, 2019 at 11:28 AM Andres Freund <andres@anarazel.de> wrote: > On 2019-02-23 11:20:02 +1300, Thomas Munro wrote: > > So, for this patch tolerating EINVAL for fsync of directories (but not > > files), enabling eg pg_backbackup on CIFS on eg Linux 3.10 to work, > > tested by John, we have: > > > > Stephen: +1 > > Michael: -0.1 > > Thomas: -0.1 > > > > Any other opinions? > > > > Just in case you think it's strange that I'm voting against my own > > patch: I'd probably be for it if I hadn't discovered that they've > > fixed this in Linux 3.16 and later so that it succeeds. It's > > apparently not in the default RHEL 6 and 7 kernels, though, and the > > latter could be around for a while. I'm not entirely sure what amount > > of work we should be doing to tolerate problems that are fixed in a > > newer versions. One argument is that a 3.10 user who cares about this > > should petition RH to back-port the fix into that kernel. (The nearby > > WSL thread has some things in common but is a more clear cut case IMV > > because there is no fix available on the WSL side.) > > Hm, given the fact that EINVAL doesn't appear to be triggerable by data > level issues, I don't see much reason not to allow it. I mean it's > really stupid that cifs ever returns it, but there's going to be a lot > of users running things on older kernel for the forseeable future. Thanks. Pushed. FTR here is the discussion about the pre-existing tolerance of EBADF for directories: https://www.postgresql.org/message-id/flat/20100215005057.5AC8F7541C5%40cvs.postgresql.org -- Thomas Munro https://enterprisedb.com
Commits
-
Tolerate EINVAL when calling fsync() on a directory.
- ede6b19624d1 9.4.22 landed
- 0ec89a0f6752 9.5.17 landed
- ad714c6072c9 9.6.13 landed
- bcf627834344 10.8 landed
- 4d67357dbf50 11.3 landed
- f16735d80d2f 12.0 landed