Simon Riggs wrote:
On Tue, 2007-09-11 at 10:21 -0400, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
