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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Borisov
Дата:
Сообщение: Re: [PATCH] Covering SPGiST index
Следующее
От: legrand legrand
Дата:
Сообщение: nested queries vs. pg_stat_activity