On 2 December 2012 16:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 2 December 2012 15:25, Tom Lane <tgl@sss.pgh.pa.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