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