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  (Christophe Pettus <xof@thebuild.com>)
Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Christophe Pettus
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Следующее
От: Christophe Pettus
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS