On 2 December 2012 15:25, Tom Lane <t...@sss.pgh.pa.us> wrote: > I can point right now to one misbehavior this causes: if you run a > point-in-time recovery with a stop point somewhere in the middle of the > checkpoint, you should end up with a nextXid corresponding to the stop > point. This hack in LogStandbySnapshot causes you to end up with a > much later nextXid, if you were running hot-standby.
True, though that does not cause any problem. >> Others may wish to go further, overriding my patches, as they choose. > > Okay, I will take the responsibility for changing this, but it needs to > change. OK. At least we have the minimal coding to fall back on if need be. > 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. -- 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
