From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add pg_file_sync() to adminpack |
Date: | 2020-01-09 17:51:06 |
Message-ID: | 4332.1578592266@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Julien Rouhaud <rjuju123(at)gmail(dot)com> writes:
> On Thu, Jan 9, 2020 at 6:16 PM Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-01-09 17:55:04 | Re: Removing pg_pltemplate and creating "trustable" extensions |
Previous Message | Daniel Verite | 2020-01-09 17:43:14 | Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR |