From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MultiXact bugs |
Date: | 2013-11-25 22:10:02 |
Message-ID: | 1385417402.55499.YahooMailNeo@web162904.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Andres Freund wrote:
>> That's because HeapTupleHeaderGetUpdateXid() ignores aborted
>> updaters and returns InvalidTransactionId in that case, but
>> HeapTupleSatisfiesVacuum() returns
>> HEAPTUPLE_DELETE_IN_PROGRESS...
> I checked for other cases where the update Xid is checked after
> HeapTupleSatisfiesVacuum returns HEAPTUPLE_DELETE_IN_PROGRESS.
> As far as I can tell, the only one that would be affected is the
> one in predicate.c. It is far from clear to me what is the right
> thing to do in these cases; the simplest idea is to return
> without reporting a failure if the updater aborted, just as
> above; but I wonder if this needs to be conditional on "visible".
> I added a pg_usleep() before acquiring the update Xid in the
> relevant case, but the isolation test cases didn't hit the
> problem (I presume there is no update/delete in these test cases,
> but I didn't check). I defer to Kevin on this issue.
Right now if HeapTupleSatisfiesVacuum() returns
HEAPTUPLE_DELETE_IN_PROGRESS we call
HeapTupleHeaderGetUpdateXid(tuple->t_data) and Assert() that the
result is valid. It sounds like we should do something like the
attached, maybe?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachment | Content-Type | Size |
---|---|---|
multi-xact-predicate-fix-v1.diff | text/x-diff | 542 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-11-25 22:23:48 | Re: PL/Python: domain over array support |
Previous Message | Mark Kirkwood | 2013-11-25 21:36:44 | Re: why semicolon after begin is not allowed in postgresql? |