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 по дате отправления: