Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
От | Andres Freund |
---|---|
Тема | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Дата | |
Msg-id | 103AD7FF-FA67-4668-8646-A3A1B235AE32@anarazel.de обсуждение исходный текст |
Ответ на | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS (Christophe Pettus <xof@thebuild.com>) |
Ответы |
Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
Список | pgsql-hackers |
On April 2, 2018 5:03:39 PM PDT, Christophe Pettus <xof@thebuild.com> wrote: > >> On Apr 2, 2018, at 16:27, Craig Ringer <craig@2ndQuadrant.com> wrote: >> >> They're undocumented and extremely surprising semantics that are >arguably a violation of the POSIX spec for fsync(), or at least a >surprising interpretation of it. > >Even accepting that (I personally go with surprising over violation, as >if my vote counted), it is highly unlikely that we will convince every >kernel team to declare "What fools we've been!" and push a change... >and even if they did, PostgreSQL can look forward to many years of >running on kernels with the broken semantics. Given that, I think the >PANIC option is the soundest one, as unappetizing as it is. Don't we pretty much already have agreement in that? And Craig is the main proponent of it? Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-hackers по дате отправления: