Re: HeapTupleHeaderAdvanceLatestRemovedXid doing the wrong thing with multixacts

On Mon, Oct 17, 2011 at 08:38:18PM +0100, Simon Riggs wrote:
> 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.

Was this completed?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +