Re: BUG #7710: Xid epoch is not updated properly during checkpoint

On 2 December 2012 16:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 2 December 2012 15:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This coding was ill-considered from the word go.
>
>> Agreed, but then I don't have a clear reason why it is that way and
>> yet I'm sure I did it for some reason.
>
> I think you just did it because it looked easy, and you didn't think
> very hard about the consequences.

I don't typically think such thoughts. Your ability to see more deeply
into certain topics is a credit to you, not an implication of laziness
on me.

I'm sure I believed it a necessary or useful thing to do.

> 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.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services