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 80B1A286-A073-417A-8968-605FE4A11B7B@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  (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 Apr 8, 2018, at 03:30, Craig Ringer <craig@2ndQuadrant.com> wrote:
>
> These are way more likely than bit flips or other storage level corruption, and things that we previously expected to
detectand fail gracefully for. 

This is definitely bad, and it explains a few otherwise-inexplicable corruption issues we've seen.  (And great work
trackingit down!)  I think it's important not to panic, though; PostgreSQL doesn't have a reputation for horrible data
integrity. I'm not sure it makes sense to do a major rearchitecting of the storage layer (especially with pluggable
storagecoming along) to address this.  While the failure modes are more common, the solution (a PITR backup) is one
thatan installation should have anyway against media failures. 

--
-- Christophe Pettus
   xof@thebuild.com



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: WIP: Covering + unique indexes.
Next
From: Tom Lane
Date:
Subject: Re: WIP: a way forward on bootstrap data