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

From Christophe Pettus
Subject Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Date
Msg-id AF90CC2E-E990-4E5B-BB06-EB3F423E5879@thebuild.com
Whole thread Raw
In response to Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Andres Freund <andres@anarazel.de>)
Responses Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
List pgsql-hackers
> On Apr 8, 2018, at 16:16, Andres Freund <andres@anarazel.de> wrote:
> We don't panic that way when getting IO
> errors during reads either, and they're more likely to be persistent
> than errors during writes (because remapping on storage layer can fix
> issues, but not during reads).

There is a distinction to be drawn there, though, because we immediately pass an error back to the client on a read,
buta write problem in this situation can be masked for an extended period of time. 

That being said...

> There's a lot of not so great things here, but I don't think there's any
> need to panic.

No reason to panic, yes.  We can assume that if this was a very big persistent problem, it would be much more widely
reported. It would, however, be good to find a way to get the error surfaced back up to the client in a way that is not
justmonitoring the kernel logs. 

--
-- Christophe Pettus
   xof@thebuild.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Next
From: Michael Paquier
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take two