On Sun, 2010-12-12 at 10:15 +0000, Simon Riggs wrote:
> > Also, I'm not totally convinced it's correct when xmin > xmax,
> > 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
> > 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
> 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
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
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-12-14 00:32:50|
|Subject: Re: rest of works for security providers in v9.1|
|Previous:||From: Robert Haas||Date: 2010-12-14 00:18:34|
|Subject: Re: Label switcher function|
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2010-12-14 01:24:24|
|Subject: pgsql: Update release notes for releases 9.0.2, 8.4.6, 8.3.13, 8.2.19,|
|Previous:||From: Robert Haas||Date: 2010-12-14 00:16:16|
|Subject: pgsql: Allow plugins to suppress inlining and hook functionentry/exit/|