Horton

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

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "Wood, Dan" <hexpert@amazon.com>
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-04T09:51:59Z
Lists: pgsql-hackers 
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.