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
