Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS - Mailing list pgsql-hackers

From Greg Stark
Subject Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Date
Msg-id CAM-w4HNH71T0chk-7jx9_VLMcz6iY-NiSn5xgCcT2UJzP9dQsg@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 10 April 2018 at 02:59, Craig Ringer <craig@2ndquadrant.com> wrote:

> Nitpick: In most cases the kernel reserves disk space immediately,
> before returning from write(). NFS seems to be the main exception
> here.

I'm kind of puzzled by this. Surely NFS servers store the data in the
filesystem using write(2) or the in-kernel equivalent? So if the
server is backed by a filesystem where write(2) preallocates space
surely the NFS server must behave as if it'spreallocating as well? I
would expect NFS to provide basically the same set of possible
failures as the underlying filesystem (as long as you don't enable
nosync of course).

-- 
greg


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump should use current_database() instead of PQdb()
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.