Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple

Sorry.  Should have looked at the macro.  I sent this too soon.  The early “break;” here is likely the xmin frozen
reasonas I found in the other loop. 
 

On 10/4/17, 2:52 AM, "Alvaro Herrera" <alvherre@alvh.no-ip.org> wrote:

    Wood, Dan wrote:
    
    > There is a tangled web of issues here.  With the community fix we get a corrupted page(invalid redirect ptr from
indexeditem).  The cause of that is:
 
    > pruneheap.c:
    > 
    >                   /*
    >                    * Check the tuple XMIN against prior XMAX, if any
    >                    */
    >                   if (TransactionIdIsValid(priorXmax) &&
    >                           !TransactionIdEquals(HeapTupleHeaderGetXmin(htup), priorXmax))
    >                           break;
    > 
    >     chainitems[nchain++] = offnum;
    > 
    > The priorXmax is a multixact key share lock,
    
    Uhh, what?  That certainly shouldn't happen -- the priorXmax comes from
    
                priorXmax = HeapTupleHeaderGetUpdateXid(htup);
    
    so only the XID of the update itself should be reported, not a multixact
    and certainly not just a tuple lock XID.
    
    -- 
    Álvaro Herrera                https://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
    

On Tue, Oct 3, 2017 at 6:09 PM, Wood, Dan <hexpert@amazon.com> wrote:
> I’ve just started looking at this again after a few weeks break.

>                 if (TransactionIdIsValid(priorXmax) &&
>                         !TransactionIdEquals(priorXmax, HeapTupleHeaderGetXmin(htup)))
>                         break;

> We need to understand why these TXID equal checks exist.  Can we differentiate the cases they are protecting against
withthe two exceptions I’ve found? 

I haven't read your remarks here in full, since I'm about to stop
working for the day, but I will point out that
src/backend/access/heap/README.HOT says a fair amount about this,
under "Abort Cases".


--
Peter Geoghegan



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