Peter Geoghegan wrote: > On Fri, Oct 6, 2017 at 8:29 AM, Alvaro Herrera <alvhe...@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
