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

Re: Recovery bug

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Recovery bug
Date: 2010-10-25 11:44:37
Message-ID: 4CC56DA5.3040908@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On 19.10.2010 22:40, Jeff Davis wrote:
> On Tue, 2010-10-19 at 09:51 -0700, Jeff Davis wrote:
>> On Tue, 2010-10-19 at 12:26 +0300, Heikki Linnakangas wrote:
>>> Excluding pg_xlog is just a recommendation at the moment, though, so we
>>> would need a big warning in the docs. And some way to enforce that
>>> just_kidding is not included in the backup would be nice, maybe we could
>>> remove read-permission from it?
>>
>> Hmm, removing the read bit would add some confidence into the process. I
>> like that idea better than just assuming that the user won't copy it.
>>
>> I think I like this direction most, because it doesn't leave us
>> guessing. If the file is there then we assume normal recovery. If we
>> encounter recovery.conf we throw FATAL. If we encounter backup_label we
>> can simply remove it (perhaps with a warning that there was a crash in
>> the middle of a backup).
>
> On second thought, this doesn't sound backpatch-friendly. We should
> probably put a simpler fix in first and back-patch it. Then we can do
> something like your proposal for 9.1. What do you think of my proposed
> patch?

Yes, let's go ahead with your original patch.

It seems we should use ReadRecord instead of the lower-level 
XLogPageRead function. One difference is that ReadRecord performs a 
bunch of sanity checks on the record, while XLogPageRead just reads the 
raw page. Extra sanity checking before removing backup_label seems like 
a good idea. Another difference is that in standby-mode, ReadRecord will 
retry until it succeeds. A standby server should keep retrying, even the 
very first record, until it succeeds, otherwise we have a change in 
behavior.

So I'm thinking of the attached patch. I'll give this some testing on 
older branches and commit.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Attachment: recovery-redo-2.patch
Description: text/x-diff (1.6 KB)

In response to

Responses

pgsql-bugs by date

Next:From: Jochen ErwiedDate: 2010-10-25 12:42:24
Subject: BUG #5722: vacuum full does not update last_vacuum statistics
Previous:From: Vincent MauryDate: 2010-10-25 10:09:25
Subject: postgresql install failure on Ubuntu 10.10

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