On Mon, May 25, 2015 at 2:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
