From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HeapTupleHeaderAdvanceLatestRemovedXid doing the wrong thing with multixacts |
Date: | 2011-10-18 02:14:53 |
Message-ID: | 1318904093.4e9ce11d4aaab@webmail.no-ip.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Monday, 10/17/2011 on 4:38 pm Simon Riggs wrote:
> On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Royce Ausburn | 2011-10-18 02:19:56 | Re: BUG or strange behaviour of update on primary key |
Previous Message | Robert Haas | 2011-10-18 02:00:02 | Re: BUG or strange behaviour of update on primary key |