Skip site navigation (1) Skip section navigation (2)

Re: pg_basebackup from cascading standby after timeline switch

From: Greg Stark <stark(at)mit(dot)edu>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup from cascading standby after timeline switch
Date: 2013-01-02 18:04:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan 2, 2013 at 1:55 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> If you take a backup with "pg_basebackup -X fetch", and the timeline
> switches while the backup is taken, you currently get an error like
> "requested WAL segment 00000001000000000000000C has already been removed".
> To fix, let's change the server-side support of "-X fetch" to include all
> WAL files between the backup start and end pointers, regardless of
> timelines. I'm thinking of doing this by scanning pg_xlog with readdir(),
> and sending over any files in that range. Another option would be to read
> and parse the timeline history file to figure out the exact filenames
> expected, but the readdir() approach seems simpler.

I'm not clear what you mean by "any files in that range". There could
be other timelines in the archive that aren't relevant to the restore
at all. For example if the database you're requesting a backup from
has previously been restored from an old backup the archive could have
archives from the original timeline as well as the active timeline.

I'm trying to wrap my head around what other combinations are
possible. Is it possible there have been other false starts or
multiple timeline switches during the time the backup was being taken?
At first blush I think not, I think it's only possible for there to be
one timeline switch and it would be when a standby database was being
backed up and is activated while the backup was being taken.


In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2013-01-02 20:29:24
Subject: Re: [COMMITTERS] pgsql: Unify some tar functionality across different parts
Previous:From: David FetterDate: 2013-01-02 17:44:39
Subject: Re: Review of Row Level Security

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group