Re: Add pg_file_sync() to adminpack - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add pg_file_sync() to adminpack
Date
Msg-id 4332.1578592266@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add pg_file_sync() to adminpack  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Thu, Jan 9, 2020 at 6:16 PM Stephen Frost <sfrost@snowman.net> wrote:
>> Why would you expect that when it isn't the case for the filesystem
>> itself..?

> Just a usual habit with durable property.

I tend to agree with Stephen on this, mainly because the point of
these adminpack functions is to expose filesystem access.  If these
functions were more "database-y" and less "filesystem-y", I'd agree
with trying to impose database-like consistency requirements.

We don't have to expose every wart of the filesystem semantics
--- for example, it would be reasonable to make pg_file_sync()
Do The Right Thing when applied to a directory, even if the
particular platform we're on doesn't behave sanely for that.
But having fsync separated from write is a pretty fundamental part
of most filesystems' semantics, so we ought not try to hide that.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR
Next
From: Robert Haas
Date:
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions