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