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

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(at)alvh(dot)no-ip(dot)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