Simon Riggs wrote:
> On Tue, 2007-09-11 at 10:21 -0400, Tom Lane wrote:
>> Simon Riggs <simon@2ndquadrant.com> writes:
>>> 1. The ProcArrayLock is acquired Exclusive-ly by only one
>>> remaining operation: XidCacheRemoveRunningXids(). Reducing things
>>> to that level is brilliant work, Florian and Tom.
>> It would be brilliant if it were true, but it isn't. Better look
>> again.
>
> On the more detailed explanation, I say "in normal operation".
>
> My analytical notes attached to the original post show ProcArrayLock
> is acquired exclusively during backend start, exit and while making a
> prepared (twophase) commit. So yes, it is locked Exclusively in
> other places, but they happen rarely and they actually add/remove
> procs from the array, so its unlikely anything can change there
> anyhow.
Well, and during normal during COMMIT and ABORT, which might happen
rather frequently ;-)
I do agree, however, that XidCacheRemoveRunningXids() is the only site
left where getting rid of it might be possible, and might bring
measurable benefit for some workloads. With more effort, we might not
even need it during ABORT, but I doubt that the effort would be worth
it. While some (plpgsql intensive) workloads might abort subxacts rather
frequently, I doubt that same holds true for toplevel aborts.
I'm actually working on a patch to remove that lock from
XidCacheRemoveRunningXids(), but I'm not yet completely sure that my
approach is safe. Tom had some objections that I take rather seriously.
We'll see ;-)
greetings, Florian Pflug
