| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Satoshi Nagayasu <snaga(at)uptime(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: inconsistent state after crash recovery |
| Date: | 2013-07-26 12:27:05 |
| Message-ID: | 13112.1374841625@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-07-26 12:32:01 | Re: Design proposal: fsync absorb linear slider |
| Previous Message | Amit Kapila | 2013-07-26 11:10:25 | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |