Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful
От | Tom Lane |
---|---|
Тема | Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful |
Дата | |
Msg-id | 9915.1432569947@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [CORE] [BUGS] BUG #13350: blindly fsyncing data dir considered harmful (Greg Stark <stark@mit.edu>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: