Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records
Date
Msg-id 1292286507.2737.3574.camel@ebony
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Label switcher function
Next
From: Robert Haas
Date:
Subject: Re: rest of works for security providers in v9.1