Stephen Frost wrote: > Further review leads me to notice that both HEAP_XMAX_IS_MULTI and > HEAP_XMAX_INVALID are set: > > t_infomask | 6528 > > 6528 decimal -> 0x1980 > > 0001 1001 1000 0000 > > Which gives us: > > 0000 0000 1000 0000 - HEAP_XMAX_LOCK_ONLY > 0000 0001 0000 0000 - HEAP_XMIN_COMMITTED > 0000 1000 0000 0000 - HEAP_XMAX_INVALID > 0001 0000 0000 0000 - HEAP_XMAX_IS_MULTI > > Which shows that both HEAP_XMAX_INVALID and HEAP_XMAX_IS_MULTI are set. > Of some interest is that HEAP_XMAX_LOCK_ONLY is also set..
This combination seems reasonable. This tuple had two FOR SHARE lockers, so it was marked HEAP_XMAX_SHARED_LOCK|HEAP_XMAX_IS_MULTI (0x1080). Then those lockers finished, and somebody else checked the tuple with a tqual.c routine (say HeapTupleSatisfiesUpdate), which saw the lockers were gone and marked it as HEAP_XMAX_INVALID (0x800), without removing the Xmax value and without removing the other bits. This is all per spec, so we must cope. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
