Re: pendingOps table is not cleared with fsync=off

Поиск
Список
Период
Сортировка
От Shawn Debnath
Тема Re: pendingOps table is not cleared with fsync=off
Дата
Msg-id 20200810210235.GB83133@f01898859afd.ant.amazon.com
обсуждение исходный текст
Ответ на Re: pendingOps table is not cleared with fsync=off  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Aug 10, 2020 at 02:50:26PM -0400, Tom Lane wrote:
>
> Shawn Debnath <sdn@amazon.com> writes:
> > 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?
> 
> No.  Or at least, expecting that you can do that from an assign hook
> is impossibly wrong-headed.  GUC assign hooks can't have failure modes.

Okay agree, will remind myself to drink more coffee next time.

If we think a fsync should be performed in this case, assign hook
could set a value to indicate parameter was reset via SIGHUP. Next call
to ProcessSyncRequests() could check for this, do a fsync prior to
absorbing the newly submitted sync requests, and reset the flag.
fsync_pgdata() comes to mind to be inclusive.

If folks are not inclined to do the fsync, the change is good as is.

-- 
Shawn Debnath
Amazon Web Services (AWS)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: autovac issue with large number of tables
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: nested queries vs. pg_stat_activity