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