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
> 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
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
* base backup was taken that we are about to rollforward from.
* If recovery has ever crashed or was stopped there is also
* another point 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.com
PostgreSQL Training, Services and Support
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2009-01-30 11:11:17|
|Subject: Re: Hot standby, recovery infra|
|Previous:||From: Patil, Smita (NSN - IN/Bangalore)||Date: 2009-01-30 11:05:12|
|Subject: Synch Replication - Synch rep 0114 |