Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <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:48:00
Message-ID: CAH2-WznVL4NVmaw52+mSLz0gFTcatuKKjRq4VPyfCCqj1iP1FQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 2, 2018 at 5:05 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>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?

I wonder how bad it will be in practice if we PANIC. Craig said "This
isn't as bad as it seems because AFAICS fsync only returns EIO in
cases where we should be stopping the world anyway, and many FSes will
do that for us". It would be nice to get more information on that.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2018-04-03 00:57:12 Re: 2018-03 Commitfest Summary (Andres #1)
Previous Message Michael Paquier 2018-04-03 00:27:05 Re: check_ssl_key_file_permissions should be in be-secure-common.c