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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: tarvip(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org, Andres Freund <andres(at)2ndQuadrant(dot)com>
Subject: Re: BUG #7710: Xid epoch is not updated properly during checkpoint
Date: 2012-12-02 16:44:32
Message-ID: 13206.1354466672@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Simon Riggs 2012-12-02 16:56:16 Re: BUG #7710: Xid epoch is not updated properly during checkpoint
Previous Message Simon Riggs 2012-12-02 15:58:25 Re: BUG #7710: Xid epoch is not updated properly during checkpoint