Re: Verified fix for Bug 4137 - Mailing list pgsql-patches

From Simon Riggs
Subject Re: Verified fix for Bug 4137
Date
Msg-id 1210116557.4435.485.camel@ebony.site
Whole thread Raw
In response to Re: Verified fix for Bug 4137  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: Verified fix for Bug 4137  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Verified fix for Bug 4137  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-patches
On Tue, 2008-05-06 at 21:51 +0100, Heikki Linnakangas wrote:

> In fact, what will happen if the checkpoint record's redo pointer points
> to an earlier xlog file:
>
> 1. The location of the checkpoint record is read by read_backup_label().
> Let's say that it's 0005.
> 2. ReadCheckpointRecord() is called for 0005. The restore command is
> called because that xlog file is not present. The safe truncation point
> is determined to be 0005, as that's what we're reading. Everything
> before that is truncated
> 3. The redo pointer in the checkpoint record points to 0003. That's
> where we should start the recovery. Oops :-(

Yes, this case could be a problem, if the records are in different
files. It's the files that matter, not the records themselves though.

I've extended the patch without introducing another new status variable,
which was my original concern with what you suggested previously.

--
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com

Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Snapshot management, final
Next
From: Tom Lane
Date:
Subject: Re: column level privileges