Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
От | Simon Riggs |
---|---|
Тема | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode |
Дата | |
Msg-id | 1245965083.4038.234.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: BUG #4879: bgwriter fails to fsync the file in recovery mode (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-bugs |
On Thu, 2009-06-25 at 22:29 +0300, Heikki Linnakangas wrote: > 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. During the end-of-recovery > checkpoint, however, RecoveryInProgress() returns false, so we don't > update minimum recovery point in XLogFlush(). You're unlikely to be > bitten by that in practice; you would need to crash during the > end-of-recovery checkpoint, and then set the recovery target to an > earlier point. It should be fixed nevertheless. RecoveryInProgress returns false only because you set LocalRecoveryInProgress at the start of the checkpoint, not at the end. It only needs to be set immediately prior to the call for XLogInsert() in CreateCheckpoint(). If we do that then XLogFlush() acts as advertised and we have no worries. Tom: Heikki's work on MinRecoveryPoint seems sound to me and altering it now seems like something too dangerous to attempt at this stage. I see no need; we have no new bug, just a minor point of how we code the fix to the bug we do have. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-bugs по дате отправления: