Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
От | Craig Ringer |
---|---|
Тема | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Дата | |
Msg-id | CAMsr+YHND7v-jFD7H5Y3EabTBHmroLRZVBYczK30b71vBk-umg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS (Andreas Karlsson <andreas@proxel.se>) |
Список | pgsql-hackers |
On 10 April 2018 at 08:41, Andreas Karlsson <andreas@proxel.se> wrote: > On 04/09/2018 02:16 PM, Craig Ringer wrote: >> >> I'd like a middle ground where the kernel lets us register our interest >> and tells us if it lost something, without us having to keep eight million >> FDs open for some long period. "Tell us about anything that happens under >> pgdata/" or an inotify-style per-directory-registration option. I'd even say >> that's ideal. > > > Could there be a risk of a race condition here where fsync incorrectly > returns success before we get the notification of that something went wrong? We'd examine the notification queue only once all our checkpoint fsync()s had succeeded, and before we updated the control file to advance the redo position. I'm intrigued by the suggestion upthread of using a kprobe or similar to achieve this. It's a horrifying unportable hack that'd make kernel people cry, and I don't know if we have any way to flush buffered probe data to be sure we really get the news in time, but it's a cool idea too. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: