Re: Streaming replication and WAL archive interactions

On Wed, Apr 22, 2015 at 3:01 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 04/22/2015 09:30 PM, Robert Haas wrote:
>> On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
>> wrote:
>>>
>>> Note that it's a bit complicated to set up that scenario today. Archiving
>>> is
>>> never enabled in recovery mode, so you'll need to use a custom cron job
>>> or
>>> something to maintain the archive that C uses. The files will not
>>> automatically flow from B to the second archive. With the patch we're
>>> discussing, however, it would be easy: just set archive_mode='always' in
>>> B.
>>
>>
>> Hmm, I see. But if C never replays the last, partial segment from the
>> old timeline, how does it follow the timeline switch?
>
> At timeline switch, we copy the old segment to the new timeline, and start
> writing where we left off. So the WAL from the old timeline is found in the
> segment nominally belonging to the new timeline.

Check.

> For example, imagine that perform point-in-time recovery to WAL position
> 0/1237E568, on timeline 1. That falls within segment
> 000000010000000000000012. Then we end recovery, and switch to timeline 2.
> After the switch, and some more WAL-logged actions, we'll have these files
> in pg_xlog:
>
> 000000010000000000000011
> 000000010000000000000012
> 000000020000000000000012
> 000000020000000000000013
> 000000020000000000000014

Is the 000000010000000000000012 file a "partial" segment of the sort
you're proposing to no longer achive?

> Note that there are two segments ending in "12". They both have the same
> point up to offset 0x37E568, corresponding to the switch point 0/1237E568.
> After that, the contents diverge: the segment on the new timeline contains a
> checkpoint/end-of-recovery record at that point, followed by new WAL
> belonging to the new timeline.

Check.

> Recovery knows about that, so that if you set recovery target to timeline 2,
> and it needs the WAL at the beginning of segment 12 (still belonging to
> timeline 1), it will try to restoring both "000000010000000000000012" and
> "000000020000000000000012".

What if you set the recovery target to timeline 3?

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