Re: PITR potentially broken in 9.2 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: PITR potentially broken in 9.2
Date
Msg-id 23095.1354676002@sss.pgh.pa.us
Whole thread Raw
In response to Re: PITR potentially broken in 9.2  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: PITR potentially broken in 9.2
List pgsql-bugs
Andres Freund <andres@2ndquadrant.com> writes:
> On 2012-12-04 21:27:34 -0500, Tom Lane wrote:
>> So the upshot is that I propose a patch more like the attached.

> Without having run anything so far it looks good to me.

BTW, while on the theme of the pause feature being several bricks shy of
a load, it looks to me like the place that it was added to the replay
loop was less than sane as well.  Presumably the purpose of a pause is
to let you stop application of the WAL at exactly the current spot;
but you can *not* do that midway through application of the record,
and where it is is effectively that.  As soon as we've updated
xlogctl->replayEndRecPtr, we're committed to replay the record,
because we can't guarantee that the controlfile minRecoveryPoint
doesn't get pushed up to that point by buffer flush activity.
So an abort here could leave the database in an unrestartable condition.

I guess the idea of putting it there was to save one spinlock acquire,
but I'm having a bit of a hard time believing that one spinlock acquire
per WAL record means much.  Still we could possibly preserve that
attribute by moving the pause down to just after the update of
xlogctl->recoveryLastRecPtr.

Thoughts?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: PITR potentially broken in 9.2
Next
From: Simon Riggs
Date:
Subject: Re: PITR potentially broken in 9.2