From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains |
Date: | 2017-10-12 23:31:52 |
Message-ID: | 20171012233152.kyk5vtccs32enk5c@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Peter Geoghegan wrote:
> On Fri, Oct 6, 2017 at 8:29 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-10-12 23:48:29 | Re: pgsql: Improve performance of SendRowDescriptionMessage. |
Previous Message | Andres Freund | 2017-10-12 23:26:32 | pgsql: Use C99 restrict via pg_restrict, rather than restrict directly. |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-10-12 23:35:34 | Re: [PATCH] pageinspect function to decode infomasks |
Previous Message | Thomas Munro | 2017-10-12 23:30:25 | Re: oversight in EphemeralNamedRelation support |