Re: fsync-pgdata-on-recovery tries to write to more files than previously

On Mon, May 25, 2015 at 9:54 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-05-25 21:33:03 -0400, Robert Haas wrote:
>> On Mon, May 25, 2015 at 2:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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