Re: pendingOps table is not cleared with fsync=off
От | Shawn Debnath |
---|---|
Тема | Re: pendingOps table is not cleared with fsync=off |
Дата | |
Msg-id | 20200810163545.GA83133@f01898859afd.ant.amazon.com обсуждение исходный текст |
Ответ на | Re: pendingOps table is not cleared with fsync=off (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: pendingOps table is not cleared with fsync=off
|
Список | 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)
В списке pgsql-hackers по дате отправления: