On Sun, 2010-12-12 at 10:15 +0000, Simon Riggs wrote: > > Also, I'm not totally convinced it's correct when xmin > xmax, > despite > > Simon's follow-up commit to fix that. Shouldn't it advance > > latestRemovedXid to xmin in that case? Or maybe it's ok as it is > because > > we know that xmax committed after xmin. The impression I get from > the comment above the function now is that it advances > latestRemovedXid to > > the highest XID present in the tuple, but that's not what it does in > the xmin > xmax case. That comment needs clarification. > > Hmmm, my earlier code took xmax only if xmax > xmin. That was wrong; > what I have now is better, but your point is there may be an even > better > truth. I'll think on that a little more.
This has a stranger answer than I was expecting. HeapTupleSatisfiesVacuum() shows there is no interaction between the xmin of a tuple and the point at which it is removed, if the xmin transaction commits. So the hot standby conflict depends only upon the xmax, meaning that xmin > xmax is not a problem. So no immediate change to the code is warranted, on that specific point. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
