At Monday, 10/17/2011 on 4:38 pm Simon Riggs wrote: > On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > >> I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing > >> Xmax as a TransactionId without verifying whether it is a multixact or > >> not. Since they advance separately, this could lead to bogus answers. > >> This probably needs to be 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.
Hmkay. > I'll add an assert to check this and a comment to explain. This means I'll have to hack it up further in my FK locks patch. No problem with that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
