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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records
Date: 2010-12-14 00:28:26
Message-ID: 1292286507.2737.3574.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2010-12-14 01:24:24 pgsql: Update release notes for releases 9.0.2, 8.4.6, 8.3.13, 8.2.19,
Previous Message Robert Haas 2010-12-14 00:16:16 pgsql: Allow plugins to suppress inlining and hook function entry/exit/

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-14 00:32:50 Re: rest of works for security providers in v9.1
Previous Message Robert Haas 2010-12-14 00:18:34 Re: Label switcher function