| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Anthony Iliopoulos <ailiop(at)altatus(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Catalin Iacob <iacobcatalin(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
| Date: | 2018-04-04 02:14:28 |
| Message-ID: | 20180404021428.GC25202@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 3, 2018 at 10:05:19PM -0400, Bruce Momjian wrote:
> On Wed, Apr 4, 2018 at 01:54:50PM +1200, Thomas Munro wrote:
> > I believe there were some problems of that nature (with various
> > twists, based on other concurrent activity and possibly different
> > fds), and those problems were fixed by the errseq_t system developed
> > by Jeff Layton in Linux 4.13. Call that "bug #1".
>
> So all our non-cutting-edge Linux systems are vulnerable and there is no
> workaround Postgres can implement? Wow.
Uh, are you sure it fixes our use-case? From the email description it
sounded like it only reported fsync errors for every open file
descriptor at the time of the failure, but the checkpoint process might
open the file _after_ the failure and try to fsync a write that happened
_before_ the failure.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-04-04 02:27:08 | Re: [HACKERS] Runtime Partition Pruning |
| Previous Message | David Rowley | 2018-04-04 02:10:54 | Re: [HACKERS] Runtime Partition Pruning |