Skip site navigation (1) Skip section navigation (2)

Re: Hot standby, recovery infra

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, recovery infra
Date: 2009-01-29 14:33:55
Message-ID: 4981BE53.2060308@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Robert TreatDate: 2009-01-29 15:22:53
Subject: Re: 8.4 release planning
Previous:From: Joshua BrindleDate: 2009-01-29 14:14:29
Subject: Re: How to get SE-PostgreSQL acceptable

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group