| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(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-03-29 02:48:27 |
| Message-ID: | CAEepm=2JnwtkZ1PAuPMx=UtG21VPQFfRrVzVTWjEPQmYR-zyng@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 29, 2018 at 3:30 PM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Tue, Mar 27, 2018 at 11:53:08PM -0400, Tom Lane wrote:
>> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
>>> TL;DR: Pg should PANIC on fsync() EIO return.
>>
>> Surely you jest.
>
> Any callers of pg_fsync in the backend code are careful enough to check
> the returned status, sometimes doing retries like in mdsync, so what is
> proposed here would be a regression.
Craig, is the phenomenon you described the same as the second issue
"Reporting writeback errors" discussed in this article?
https://lwn.net/Articles/724307/
"Current kernels might report a writeback error on an fsync() call,
but there are a number of ways in which that can fail to happen."
That's... I'm speechless.
--
Thomas Munro
http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2018-03-29 03:44:05 | Re: [HACKERS] Transactions involving multiple postgres foreign servers |
| Previous Message | Michael Paquier | 2018-03-29 02:33:24 | Re: Small proposal to improve out-of-memory messages |