Re: BUG #8470: 9.3 locking/subtransaction performance regression

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: os(at)ohmu(dot)fi
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8470: 9.3 locking/subtransaction performance regression
Date: 2013-12-23 19:53:00
Message-ID: 20131223195300.GK22570@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
0001-Optimize-locking-a-tuple-already-locked-by-another-s.patch text/x-diff 11.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2013-12-23 20:06:28 Re: BUG #8470: 9.3 locking/subtransaction performance regression
Previous Message balazs 2013-12-23 18:43:37 BUG #8698: cast and view