Re: BUG #8470: 9.3 locking/subtransaction performance regression - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #8470: 9.3 locking/subtransaction performance regression
Date
Msg-id 20131223195300.GK22570@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: BUG #8470: 9.3 locking/subtransaction performance regression  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BUG #8470: 9.3 locking/subtransaction performance regression  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: BUG #8470: 9.3 locking/subtransaction performance regression  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-bugs
Alvaro Herrera wrote:

> ... in particular, this change allows us to revert the addition of
> MultiXactHasRunningRemoteMembers(), and simply use
> MultiXactIdIsRunning() in the two places that required it.

And doing that enables simplifying this patch a bit, so here it is one
more time.  Hopefully this is the final version -- I intend to push it
to 9.3 and master.

Please *note the behavior change* of HeapTupleSatisfiesUpdate: it will
now return HeapTupleBeingUpdated when a tuple is locked by an Xid that's
a subtransaction of the current top transactionn.  That case previously
returned HeapTupleBeingUpdated.  If someone wants to say that we
shouldn't change that in 9.3, please speak up.  But do note that it was
already returning that valu ewhen the lock was a multixact, so the new
behavior can be said to be more consistent.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-bugs by date:

Previous
From: balazs@obiserver.hu
Date:
Subject: BUG #8698: cast and view
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #8470: 9.3 locking/subtransaction performance regression