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 20131223162903.GJ22570@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
List pgsql-bugs
Alvaro Herrera wrote:

> I have more confidence in this patch than in the previous version,
> despite it being more intrusive.  The fact that it allows us to get rid
> of some very strange coding in pgrowlocks is comforting: we now know
> that anytime a tuple is locked we will get BeingUpdated from
> HeapTupleSatisfiesUpdate, regardless of *who* locked it, and all the
> callers are able to identify this case and act in consequence.  This
> seems saner in concept that sometimes returning MayBeUpdated, because
> that turns each such return into a condition that must be double-checked
> by callers.  This means cleaner code in pgrowlocks around a HTSU call,
> for instance.  Also, we have discussed and seriously considered this
> idea in several occasions previously in connection with other things.

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

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

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #8470: 9.3 locking/subtransaction performance regression
Next
From: Brett Neumeier
Date:
Subject: Re: BUG #8684: Tables with custom range domain type cannot be analyzed