On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing Xmax as a TransactionId without verifying
whetherit is a multixact or not. Since they advance separately, this could lead to bogus answers. This probably needs
tobe fixed. I didn't look into past releases to see if there's a live released bug here or not.
>
>> I think the fix is simply to ignore the Xmax if the HEAP_XMAX_IS_MULTI bit is set.
>
>> Additionally I think it should check HEAP_XMAX_INVALID before reading the Xmax at all.
>
> If it's failing to even check XMAX_INVALID, surely it's completely
> broken? Perhaps it assumes its caller has checked all this?
HeapTupleHeaderAdvanceLatestRemovedXid() is only ever called when
HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DEAD, which only happens
when HEAP_XMAX_IS_MULTI is not set.
I'll add an assert to check this and a comment to explain.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services