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 4D807834-B7E2-4D61-8EEE-E72DA7CAAF69@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  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
> On Apr 7, 2018, at 19:33, Bruce Momjian <bruce@momjian.us> wrote:
> Idea 4 would be for people to assume their database is corrupt if their
> server logs report any I/O error on the file systems Postgres uses.

Pragmatically, that's where we are right now.  The best answer in this bad situation is (a) fix the error, then (b)
replayfrom a checkpoint before the error occurred, but it appears we can't even guarantee that a PostgreSQL process
willbe the one to see the error. 

--
-- Christophe Pettus
   xof@thebuild.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Next
From: Alvaro Herrera
Date:
Subject: Re: pgsql: Support partition pruning at execution time