From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Raphael Hertzog <hertzog(at)debian(dot)org> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Fails to work on live images due to fsync() on pg_commit_ts before doing any write there |
Date: | 2017-11-07 15:13:47 |
Message-ID: | 20171107151347.77vumrbitqbzdzaf@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2017-11-07 16:06:02 +0100, Raphael Hertzog wrote:
> On Tue, 07 Nov 2017, Stephen Frost wrote:
> > Raphael,
> >
> > * Raphael Hertzog (hertzog(at)debian(dot)org) wrote:
> > > Still I believe that this issue should be fixed in both sides. It's not
> > > smart from PostgreSQL to call fsync() when it has not made any change.
> >
> > Why?
>
> Because it's useless. Why call fsync() when you know that it doesn't do
> anything?
It's not generally useless, no. You don't know if the relevant directory
hasn't been modified since postgres was started last / crashed
last. That matters for the durability and atomicity of renames
etc. There's simply no way to track that in postgres, given it's
arbitrary external effects.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Raphael Hertzog | 2017-11-07 15:23:21 | Re: Fails to work on live images due to fsync() on pg_commit_ts before doing any write there |
Previous Message | Tom Lane | 2017-11-07 15:06:55 | Re: Fails to work on live images due to fsync() on pg_commit_ts before doing any write there |