From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
---|---|
To: | Anthony Iliopoulos <ailiop(at)altatus(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-09 12:03:28 |
Message-ID: | CAEzk6fcMUB4v5zek5YofPgwACD_y+Vh=bFQf6w_PRRrf1NQnaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9 April 2018 at 11:50, Anthony Iliopoulos <ailiop(at)altatus(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2018-04-09 12:04:15 | Re: Optimizing nested ConvertRowtypeExpr execution |
Previous Message | Teodor Sigaev | 2018-04-09 11:43:41 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |