Re: [HACKERS] [COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Peter Geoghegan wrote:
> On Fri, Oct 6, 2017 at 8:29 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> >     /*
> >      * When a tuple is frozen, the original Xmin is lost, but we know it's a
> >      * committed transaction.  So unless the Xmax is InvalidXid, we don't know
> >      * for certain that there is a match, but there may be one; and we must
> >      * return true so that a HOT chain that is half-frozen can be walked
> >      * correctly.
> >      *
> >      * We no longer freeze tuples this way, but we must keep this in order to
> >      * interpret pre-pg_upgrade pages correctly.
> >      */
> >     if (TransactionIdEquals(xmin, FrozenTransactionId) &&
> >         TransactionIdIsValid(xmax))
> >         return true;
> >
> >     return false;
> > }
> 
> Wouldn't this last "if" test, to cover the pg_upgrade case, be better
> targeted by comparing *raw* xmin to FrozenTransactionId? You're using
> the potentially distinct xmin value returned by
> HeapTupleHeaderGetXmin() for the test here. I think we should be
> directly targeting tuples frozen on or before 9.4 (prior to
> pg_upgrade) instead.

Yes, agreed, I should change that.  Thanks for continuing to think about
this.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers