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

From Craig Ringer
Subject Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Date
Msg-id CAMsr+YFFYO1eHTGzT1wnoRW6L_PmP8MDFhbcdVBjBKQSF9fkYw@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Bruce Momjian <bruce@momjian.us>)
Responses Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Antonis Iliopoulos <ailiop@altatus.com>)
List pgsql-hackers
On 4 April 2018 at 22:25, Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Apr  4, 2018 at 10:09:09PM +0800, Craig Ringer wrote:
> On 4 April 2018 at 22:00, Craig Ringer <craig@2ndquadrant.com> wrote:
>  
>
>     It's the error reporting issues around closing and reopening files with
>     outstanding buffered I/O that's really going to hurt us here. I'll be
>     expanding my test case to cover that shortly.
>
>
>
> Also, just to be clear, this is not in any way confined to xfs and/or lvm as I
> originally thought it might be. 
>
> Nor is ext3/ext4's errors=remount-ro protective. data_err=abort doesn't help
> either (so what does it do?).

Anthony Iliopoulos reported in this thread that errors=remount-ro is
only affected by metadata writes.

Yep, I gathered. I was referring to data_err.  

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Dmitry Ivanov
Date:
Subject: Re: new function for tsquery creartion
Next
From: Aleksandr Parfenov
Date:
Subject: Re: new function for tsquery creartion