Re: pendingOps table is not cleared with fsync=off

Shawn Debnath <sdn@amazon.com>

From: Shawn Debnath <sdn@amazon.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-08-10T16:35:56Z
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@iki.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)



Commits

  1. Move check for fsync=off so that pendingOps still gets cleared.

  2. Refactor the fsync queue for wider use.