| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | 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>, 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>, 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-08 23:10:24 |
| Message-ID: | 9C75D1DF-B269-4D98-A554-FCEDE66D3C60@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Apr 8, 2018, at 15:29, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I think the big problem is that we don't have any way of stopping
> Postgres at the time the kernel reports the errors to the kernel log, so
> we are then returning potentially incorrect results and committing
> transactions that might be wrong or lost.
Yeah, it's bad. In the short term, the best advice to installations is to monitor their kernel logs for errors (which very few do right now), and make sure they have a backup strategy which can encompass restoring from an error like this. Even Craig's smart fix of patching the backup label to recover from a previous checkpoint doesn't do much good if we don't have WAL records back that far (or one of the required WAL records also took a hit).
In the longer term... O_DIRECT seems like the most plausible way out of this, but that might be popular with people running on file systems or OSes that don't have this issue. (Setting aside the daunting prospect of implementing that.)
--
-- Christophe Pettus
xof(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-04-08 23:16:25 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
| Previous Message | Bruce Momjian | 2018-04-08 22:29:16 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |