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

From Geoff Winkless
Subject Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Date
Msg-id CAEzk6fcMUB4v5zek5YofPgwACD_y+Vh=bFQf6w_PRRrf1NQnaQ@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  (Anthony Iliopoulos <ailiop@altatus.com>)
Responses Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
List pgsql-hackers
On 9 April 2018 at 11:50, Anthony Iliopoulos <ailiop@altatus.com> wrote:
What you seem to be asking for is the capability of dropping
buffers over the (kernel) fence and idemnifying the application
from any further responsibility, i.e. a hard assurance
that either the kernel will persist the pages or it will
keep them around till the application recovers them
asynchronously, the filesystem is unmounted, or the system
is rebooted.

That seems like a perfectly reasonable position to take, frankly.

The whole _point_ of an Operating System should be that you can do exactly that. As a developer I should be able to call write() and fsync() and know that if both calls have succeeded then the result is on disk, no matter what another application has done in the meantime. If that's a "difficult" problem then that's the OS's problem, not mine. If the OS doesn't do that, it's _not_doing_its_job_.

Geoff

pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Optimizing nested ConvertRowtypeExpr execution