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

From Bruce Momjian
Subject Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Date
Msg-id 20180404142547.GA10462@momjian.us
Whole thread Raw
In response to Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
List pgsql-hackers
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.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Rewrite of pg_dump TAP tests
Next
From: Dmitry Ivanov
Date:
Subject: Re: new function for tsquery creartion