Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Wood, Dan <hexpert@amazon.com>

From: "Wood, Dan" <hexpert@amazon.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael.paquier@gmail.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, "Wong, Yi Wen" <yiwong@amazon.com>
Date: 2017-10-04T18:00:41Z
Lists: pgsql-hackers
Sorry.  Should have looked at the macro.  I sent this too soon.  The early “break;” here is likely the xmin frozen reason as 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 indexed item).  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
    

Commits

  1. Backport addition of rs_old_rel to rewriteheap's state.

  2. Perform a lot more sanity checks when freezing tuples.

  3. Revert bogus fixes of HOT-freezing bug

  4. Fix traversal of half-frozen update chains

  5. Fix freezing of a dead HOT-updated tuple

  6. During index build, check and elog (not just Assert) for broken HOT chain.

  7. Fix WAL replay of locking an updated tuple

  8. Change the way we mark tuples as frozen.