Re: BUG #7710: Xid epoch is not updated properly during checkpoint - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #7710: Xid epoch is not updated properly during checkpoint
Date
Msg-id 14320.1354470251@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #7710: Xid epoch is not updated properly during checkpoint  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-bugs
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 2 December 2012 16:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> As far as the concern about new bugs is concerned: if we start replay
>> from this checkpoint, we will certainly not consider that the DB is
>> consistent until we reach the checkpoint's physical position.  And by
>> that point we'll have replayed the XLOG_RUNNING_XACTS record emitted by
>> LogStandbySnapshot, so our idea of the nextXid should be fully up to
>> date anyway.  The same goes for checkpoints encountered later in the
>> replay run --- they'd just be duplicative of the preceding
>> XLOG_RUNNING_XACTS record.  There is no reason to put the same XID into
>> the checkpoint record.

> Exactly, the end result is identical, but the intermediate states may differ.

Indeed, and the intermediate states are *wrong*, as things stand.  But
they won't be visible to backends AFAICS, since we aren't allowing any
backends in yet.  I'm more concerned about the possible effects on tools
that scan WAL --- and in that connection, it's not apparent to me that
your "minimal fix" is any safer than the other change.  It's a
behavioral change either way.  I think correct tools shouldn't have a
problem either way, but it seems to me to be real hard to argue that
buggy tools would be affected by one change but not the other.  More
likely it could go either way depending on the nature of the bug.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Simon Riggs
Date:
Subject: Re: BUG #7710: Xid epoch is not updated properly during checkpoint
Next
From: Tom Lane
Date:
Subject: Re: PITR potentially broken in 9.2