Re: pendingOps table is not cleared with fsync=off

From: Shawn Debnath <sdn(at)amazon(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pendingOps table is not cleared with fsync=off
Date: 2020-08-10 16:35:56
Message-ID: 20200810163545.GA83133@f01898859afd.ant.amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 09, 2020 at 11:53:13AM +1200, Thomas Munro wrote:

> On Sat, May 9, 2020 at 9:21 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > I noticed that commit 3eb77eba5a changed the logic in
> > ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off,
> > the entries are not removed from the pendingOps hash table. I don't
> > think that was intended.
>
> Perhaps we got confused about what the comment "... so that changing
> fsync on the fly behaves sensibly" means. Fsyncing everything you
> missed when you turn it back on after a period running with it off
> does sound a bit like behaviour that someone might want or expect,
> though it probably isn't really enough to guarantee durability,
> because requests queued here aren't the only fsyncs you missed while
> you had it off, among other problems.

Good catch. Question is, are the users aware of the requirement to do a
manual fsync if they flip the fsync GUC off and then on? Should we do
this on their behalf to make a good faith attempt to ensure things are
flushed properly via an assign hook?

--
Shawn Debnath
Amazon Web Services (AWS)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message legrand legrand 2020-08-10 16:51:40 nested queries vs. pg_stat_activity
Previous Message Pavel Borisov 2020-08-10 16:14:40 Re: [PATCH] Covering SPGiST index