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

On Mon, May 25, 2015 at 2:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2015-05-25 14:14:10 -0400, Stephen Frost wrote:
>>>> Additionally we could attempt to fsync with a readonly fd before trying
>>>> the read-write fd...
>
>>> Not really sure I see that as helping.
>
>> On most OSs, except windows and some obscure unixes, a readonly fd is
>> allowed to fsync a file.
>
> 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. If they are
not writable but somehow still ours, we probably can't have written
them before the crash, either. If they are ours and we somehow wrote
to them before the crash, and then while the system was down they were
made inaccessible, and then the database was restarted, then we're
well into the territory where the system administrator has done
something that we cannot possibly be expected to cope with ... but
ignoring the fsync isn't very likely to cause any real problems even
here. If we really did modify those blocks recently, recovery will
try to redo the changes, and we'll fail then anyway. So what's the
problem?

I agree with Tom's concern that if we have two lists of directories,
they may get out of sync. We could probably merge the two lists
somehow, but I'm not really seeing the point, since Tom's blanket
approach should work just fine.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company