| From: |
| Thomas Munro <thomas.munro-AT-enterprisedb.com> |
| To: |
| Catalin Iacob <iacobcatalin-AT-gmail.com> |
| Subject: |
| Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
| Date: |
| Mon, 2 Apr 2018 06:24:51 +1200 |
| Message-ID: |
| <CAEepm=0B9f0O7jLE3ipUTqC3V6NO2LNbwE9Hp=3BxGbZPqEyQg@mail.gmail.com> |
| Cc: |
| Craig Ringer <craig-AT-2ndquadrant.com>, Tom Lane <tgl-AT-sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers-AT-postgresql.org> |
On Fri, Mar 30, 2018 at 10:18 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> ... on Linux only.
Apparently I was too optimistic. I had looked only at FreeBSD, which
keeps the page around and dirties it so we can retry, but the other
BSDs apparently don't (FreeBSD changed that in 1999). From what I can
tell from the sources below, we have:
Linux, OpenBSD, NetBSD: retrying fsync() after EIO lies
FreeBSD, Illumos: retrying fsync() after EIO tells the truth
Maybe my drive-by assessment of those kernel routines is wrong and
someone will correct me, but I'm starting to think you might be better
to assume the worst on all systems. Perhaps a GUC that defaults to
panicking, so that users on those rare OSes could turn that off? Even
then I'm not sure if the failure mode will be that great anyway or if
it's worth having two behaviours. Thoughts?
http://mail-index.netbsd.org/netbsd-users/2018/03/30/msg0...
https://github.com/NetBSD/src/blob/trunk/sys/kern/vfs_bio...
https://github.com/openbsd/src/blob/master/sys/kern/vfs_b...
https://github.com/freebsd/freebsd/blob/master/sys/kern/v...
https://github.com/freebsd/freebsd/commit/e4e8fec98ae9863...
https://github.com/illumos/illumos-gate/blob/master/usr/s...
--
Thomas Munro
http://www.enterprisedb.com
