Message-ID: <5537EFEF.6060808@iki.fi>
Date: Wed, 22 Apr 2015 22:01:03 +0300
From: Heikki Linnakangas <hlinnaka@iki.fi>
Reply-To: hlinnaka@iki.fi
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.6.0
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: Michael Paquier <michael.paquier@gmail.com>,
 Venkata Balaji N <nag1010@gmail.com>,
 Andres Freund <andres@anarazel.de>, Fujii Masao <masao.fujii@gmail.com>,
 Borodin Vladimir <root@simply.name>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Streaming replication and WAL archive interactions
References: <548AF1CB.80702@vmware.com>
	<689EB259-44C2-4820-B901-4F6B1C55A1E4@simply.name>
	<549083D6.1000301@vmware.com>
	<CAHGQGwGJzp-QS7BODiv1uc291gAKtjzzCPb_nzUTxYKJhLsUCA@mail.gmail.com>
	<54949108.3030109@vmware.com>
	<CAEyp7J9Hy8Q__FbGeR5skjk7d0dvLC+KLXB3JUuWrXXdJ5O+Wg@mail.gmail.com>
	<552FA38F.9060005@iki.fi>
	<CAB7nPqQE179yogtg+nKvdwt9KROxTyt-EjumKOMbuXQtea5r3w@mail.gmail.com>
	<5535FE71.1010905@iki.fi>
	<CAB7nPqS=V=LF-JZsv9eGF84joQ3jxugt4gkOK6kD1CiB98_vWg@mail.gmail.com>
	<55362CAD.2000207@iki.fi>
	<CA+TgmoZhcbyDBr8UdGu=y5kmnVcSwcnaBqqV=UnP+oCGiNQGeQ@mail.gmail.com>
	<55373D17.5050706@iki.fi>
 <CA+Tgmoa_Fwi+q4EKu+SYszowBN5k5LYDY4VkFOtmzkez2PdYLg@mail.gmail.com>
In-Reply-To: 
 <CA+Tgmoa_Fwi+q4EKu+SYszowBN5k5LYDY4VkFOtmzkez2PdYLg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 04/22/2015 09:30 PM, Robert Haas wrote:
> On Wed, Apr 22, 2015 at 2:17 AM, Heikki Linnakangas <hlinnaka@iki.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.

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

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.

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".

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers