| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org,Christophe Pettus <xof(at)thebuild(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
| Date: | 2018-04-03 00:05:09 |
| Message-ID: | 103AD7FF-FA67-4668-8646-A3A1B235AE32@anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On April 2, 2018 5:03:39 PM PDT, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
>> On Apr 2, 2018, at 16:27, Craig Ringer <craig(at)2ndQuadrant(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christophe Pettus | 2018-04-03 00:07:41 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
| Previous Message | Christophe Pettus | 2018-04-03 00:03:39 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |