Re: pitr replica dies on startup

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