On Mon, May 25, 2015 at 9:54 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-05-25 21:33:03 -0400, Robert Haas wrote: >> On Mon, May 25, 2015 at 2:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > Perhaps, but if we didn't have permission to write the file, it's hard to >> > argue that it's our responsibility to fsync it. So this seems like it's >> > adding complexity without really adding any safety. >> >> I agree. I think ignoring fsync failures is a very sensible approach. >> If the files are not writable, they're probably not ours. > > The reason we started discussing this is because Tom had the - quite > reasonable - concern that this might not solely be a problem of EACCESS, > but that there could be other errors that we need to ignore to not fail > spuriously. Say a symlink goes to a binary, which is currently being > executed: ETXTBSY. Or the file is in a readonly filesystem: EROFS. So > we'd need to ignore a lot of errors, possibly ignoring valid ones.
But ignoring those errors wouldn't compromise data integrity, either. So let's just ignore (but log) all errors: then we'll be demonstrably no worse off than we were before this patch went in. If it turns out that there's some particular case where ignoring errors DOES compromise data integrity, then we can plug that hole surgically when somebody reports it. Anything we do short of making all errors in this area non-fatal is going to leave behind startup-failure cases that exist today, and we have no evidence at this time that such startup failures would be justified by any actual data loss risk. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers