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

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