Re: Hot standby, recovery infra
От | Simon Riggs |
---|---|
Тема | Re: Hot standby, recovery infra |
Дата | |
Msg-id | 1233313585.8859.15.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Hot standby, recovery infra (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
On Fri, 2009-01-30 at 11:33 +0200, Heikki Linnakangas wrote: > I just realized that the new minSafeStartPoint is actually exactly the > same concept as the existing minRecoveryPoint. As the recovery > progresses, we could advance minRecoveryPoint just as well as the new > minSafeStartPoint. > > Perhaps it's a good idea to keep them separate anyway though, the > original minRecoveryPoint might be a useful debugging aid. Or what do > you think? I think we've been confusing ourselves substantially. The patch already has everything it needs, but there is a one-line-fixable bug where Fujii-san says. The code comments already explain how this works * There are two points in the log that we must pass. The first* is minRecoveryPoint, which is the LSN at the time the* basebackup was taken that we are about to rollforward from.* If recovery has ever crashed or was stopped there is also* anotherpoint also: minSafeStartPoint, which we know the* latest LSN that recovery could have reached prior to crash. The later message FATAL WAL ends before end time of backup dump was originally triggered if if (XLByteLT(EndOfLog, ControlFile->minRecoveryPoint)) and I changed that. Now I look at it again, I see that the original if test, shown above, is correct and should not have been changed. Other than that, I don't see the need for further change. Heikki's suggestions to write a new minSafeStartPoint are good ones and fit within the existing mechanisms and meanings of these variables. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: