Simon Riggs wrote:
On Thu, 2009-01-29 at 15:31 +0200, Heikki Linnakangas wrote:
Now when we restart the recovery, we will never reach
minSafeStartPoint, which is now 0/4000000, and we'll fail with the
error that Fujii-san pointed out. We're already way past the min
recovery point of base backup by then.
The problem was that we reported this error
FATAL: WAL ends before end time of backup dump
and this is inappropriate because, as you say, we are way past the min
recovery point of base backup.
If you look again at my proposal you will see that the proposal avoids
the above error by keeping track of whether we are past the point of
base backup or not. If we are still in base backup we get the error and
if we are passed it we do not.
Oh, we would simply ignore the fact that we haven't reached the
minSafeStartPoint at the end of recovery, and start up anyway. Ok, that
would avoid the problem Fujii-san described. It's like my suggestion of
ignoring the message if we're at minSafeStartPoint - 1 segment, just
more lenient. I don't understand why you'd need a new control file
state, though.
You'd lose the extra protection minSafeStartPoint gives, though. For
example, if you interrupt recovery and move recovery point backwards, we
could refuse to start up when it's not safe to do so. It's currently a
"don't do that!" case, but we could protect against that with
minSafeStartPoint.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
