On 2 December 2012 16:44, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> On 2 December 2012 15:25, Tom Lane <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
