Re: pitr replica dies on startup

[Jeff Frost <jeff(at)frostconsultingllc(dot)com>]

On Fri, 31 Aug 2007, Jeff Frost wrote:

> On Fri, 31 Aug 2007, Tom Lane wrote:
>
> > Jeff Frost <jeff(at)frostconsultingllc(dot)com> writes:
> > > Why does it request it twice?
> >
> > I think the reason is that the rollforward cycle is
> >
> > 	fetch next segment into RECOVERYXLOG
> > 	process segment
> > 	unlink RECOVERYXLOG
> >
> > and only when the "fetch" step fails does it realize it's done.  So then
> > it has to figure out which segment it wants to start extending and fetch
> > that into the real name of the segment.
> >
> > We could probably rejigger this to avoid a duplicate fetch in common
> > cases, but I'm worried that we couldn't guarantee it in every case ---
> > edge cases like the last valid xlog record ending right at a segment
> > boundary might be trouble.  If the recovery script has to handle the
> > situation sometimes, it's probably best to make it do so on a regular
> > basis ---
>
> That all seems reasonable enough.  Is it in the docs somewhere?  I didn't 
> find anything like this mentioned.  If not, could we get it added as a note?
>
>
> > would you like to have only found out about this when you were
> > trying to revive your database at 4AM?
>
> Oh, definitely not!  But then again, that's why I was testing it. :-)  I just 
> wish the guy who came before me and wrote the script had tested it.  But, no 
> big deal, I'll just update the script to deal with it.
>
> As always, thanks Tom!  I'll report back if that's the fix.

Sure enough, commenting out the mv fixes the problem.  Now everything starts 
up just fine.  So, I'll have to re-engineer the script not to do that.

Thanks again Tom!

--
Jeff Frost, Owner 	<jeff(at)frostconsultingllc(dot)com>
Frost Consulting, LLC 	http://www.frostconsultingllc.com/
Phone: 650-780-7908	FAX: 650-649-1954