Greg Stark <stark@mit.edu> writes:
> What exactly is failing?
> Is it that fsync is returning -1 ?
According to the original report from Christoph Berg, it was open()
not fsync() that was failing, at least in permissions-based cases.
I'm not sure if we should just uniformly ignore all failures in this
phase. That would have the merit of clearly not creating any new
startup failure cases compared to the previous code, but as you say
sometimes it might mean ignoring real problems.
Another idea would be to elog(LOG) such failures but press on anyway.
Lastly, there is a difference between ignoring failures in fsync_fname()
and ignoring failures in walkdir(). The latter is presumably a general
purpose subroutine and so I would expect it to throw errors if it gets a
failure in, say, opendir(). Which it does. But do we want that in this
context? Unreadable directories underneath $PGDATA are probably not a
good thing, but OTOH this would still mean that there's a new startup
failure condition compared to before.
regards, tom lane
