Re: exitArchiveRecovery woes

On Thu, Dec 18, 2014 at 10:49 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 12/18/2014 03:53 PM, Robert Haas wrote:
>> On Wed, Dec 17, 2014 at 8:40 AM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>>
>>> At the end of archive recovery, we copy the last segment from the old
>>> timeline, to initialize the first segment on the new timeline. For
>>> example,
>>> if the timeline switch happens in the middle of WAL segment
>>> 000000010000000000000005, the whole 000000010000000000000005 segment is
>>> copied to become 000000020000000000000005. The copying is necessary, so
>>> that
>>> the new segment contains valid data up to the switch point.
>>>
>>> However, we wouldn't really need to copy the whole segment, copying up to
>>> the switch point would be enough. In fact, copying the whole segment is a
>>> bad idea, because the copied WAL looks valid on the new timeline too.
>>
>>
>> Your proposed change makes sense to me, but why do we need the segment
>> to contain valid data up to the switch point? It seems like the
>> switch between timelines should be "crisper": replay WAL on the old
>> timeline only from the old segment, and from the new timeline only on
>> the new segment. Anything else seems like an invitation to unending
>> corner-case bugs.
>
> True. That would require some changes to the way archive recovery works,
> though. Currently, when our recovery target timeline is, for example, 5,
> whose parents are 4 and 3, and we're currently on timeline 3, we will try to
> restore each segment first with timeline ID 5, then 4, then 3. It's a bit
> silly, because we know the timeline history and the exact points where the
> timelines changed, so we could just fetch the correct one. That would be a
> good idea, but I'm going to go ahead with just this smaller change now.

Yeah, it's a separate issue.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company