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

Re: Hot standby, recovery infra

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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-30 11:06:25
Message-ID: 1233313585.8859.15.camel@ebony.2ndQuadrant (view raw, whole thread or download thread mbox)
Lists: 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
	* 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 
 PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 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

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