Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
Дата | |
Msg-id | 4A43D695.90404@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
|
Список | pgsql-bugs |
Tom Lane wrote: > I wrote: >> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >>> Hmm, I see another small issue. We now keep track of the "minimum >>> recovery point". Whenever a data page is flushed, we set minimum >>> recovery point to the LSN of the page in XLogFlush(), instead of >>> fsyncing WAL like we do in normal operation. > >> We would want the end-of-recovery checkpoint to act like it's not in >> recovery anymore for this purpose, no? > > Actually, what in the world is the purpose of that code at all? > I can't see a case where it would trigger that wouldn't be a result > of data corruption rather than a real need to advance the min restart > point. Huh? The only other place where we advance minimum recovery point is CreateRestartPoint() when we skip the restartpoint. The UpdateMinRecoveryPoint() call in XLogFlush() is what we rely on. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: