Re: Hot standby, recovery infra - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Hot standby, recovery infra
Date
Msg-id 4981F6E0.2040503@enterprisedb.com
Whole thread Raw
In response to Re: Hot standby, recovery infra  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Hot standby, recovery infra  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Hot standby, recovery infra  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Heikki Linnakangas wrote:
> 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.

Hmm, another point of consideration is how this interacts with the 
pause/continue. In particular, it was suggested earlier that you could 
put an option into recovery.conf to start in paused mode. If you pause 
recovery, and then stop and restart the server, and have that option in 
recovery.conf, I would expect that when you enter consistent recovery 
you're at the exact same paused location as before stopping the server. 
The upshot of that is that we need to set minSafeStartPoint to that 
exact location, at least when you pause & stop in a controlled fashion.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Commitfest infrastructure (was Re: 8.4 release planning)
Next
From: Josh Berkus
Date:
Subject: Re: Commitfest infrastructure (was Re: 8.4 release planning)