Re: BUG #4796: Recovery followed by backup creates unrecoverable WAL-file - Mailing list pgsql-bugs

From Mikael Krantz
Subject Re: BUG #4796: Recovery followed by backup creates unrecoverable WAL-file
Date
Msg-id 726863a30905070056m64da2f4fp2ca3fc32b2de34a3@mail.gmail.com
Whole thread Raw
In response to Re: BUG #4796: Recovery followed by backup creates unrecoverable WAL-file  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: BUG #4796: Recovery followed by backup creates unrecoverable WAL-file
List pgsql-bugs
On Wed, May 6, 2009 at 6:26 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>> How to reproduce:
>>
>> =A0* restore from backup
>> =A0* SELECT pg_start_backup('label');
>> =A0* take a new backup
>> =A0* SELECT pg_stop_backup();
>> =A0* copy the relevant WAL-files
>> =A0* try to restore the backup
>
> I failed to reproduce this. Is it possible that the history file went
> missing in the process? That's needed to recover WAL files from timelines
> other than the latest one. You should only get that "unexpected timeline =
ID"
> message if the history file doesn't contain a line for that timeline ID.

Yes that's true. The history file is not included in the backup. It is
archived before the backup starts and is not included in the
range specified in the backup file (e.g:
0000003B00000004000000FC.00000020.backup).

Doesn't this mean that the range of log-files in the backup file is
incorrect? If the first WAL-file in the range contain records
referring to earlier timelines I will have to backup the .history-file
of that timeline in addition to the WAL-files explicitly required for
the backup. Or force a switch of log-files before starting the backup
as I'm currently doing.

The reason I stumbled onto this is that I've setup an automatic test
that sets up a warm standby, fails over, sets up a new warm server and
so on. This causes me to take new base backups very soon after a
finished recovery process.

/M

pgsql-bugs by date:

Previous
From: Peter Much
Date:
Subject: WARNING: silent data corruption possible from PL/ruby 0.5.0 (after Ruby upgrade)
Next
From: Dave Page
Date:
Subject: Re: BUG #4785: Installation fails