Re: inconsistent state after crash recovery - Mailing list pgsql-hackers

From Robert Haas
Subject Re: inconsistent state after crash recovery
Date
Msg-id CA+TgmoYapNH2nDE15yMkRt61X4by+5bfGRgetyt-gDbQW-uXmQ@mail.gmail.com
Whole thread Raw
In response to Re: inconsistent state after crash recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: inconsistent state after crash recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jul 26, 2013 at 8:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> On 2013-07-26 13:33:13 +0900, Satoshi Nagayasu wrote:
>>> Is this expected or acceptable?
>
>> I'd say it's both.
>
> Postgres is built on the assumption that the underlying filesystem is
> reliable, ie, once you've successfully fsync'd some data that data won't
> disappear.  If the filesystem fails to honor that contract, it's a
> filesystem bug not a Postgres bug.  Nor is it reasonable to expect
> Postgres to be able to detect every such violation.  As an example,
> would you expect crash recovery to notice the disappearance of a file
> that was touched nowhere in the replayed actions?

Eh, maybe not.  But should we try harder to detect the unexpected
disappearance of one that is?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: Robert Haas
Date:
Subject: Re: Add json_typeof() and json_is_*() functions.