Andres Freund <and...@2ndquadrant.com> writes: > On 2013-11-27 17:25:44 -0500, Tom Lane wrote: >> Or we >> could add a restriction to EligibleForRelationFastPath that restricts >> the fast-path mechanism to non-session locks, in which case we'd not >> need to make the zeroing contingent on allLocks either. I don't think >> we take any fast-path-eligible locks in session mode anyway, so this >> wouldn't be giving up any functionality on that end.
> That seems like the best thing to do to me. I poked a bit more at this and realized that what I had in mind above doesn't work: a session lock isn't a distinct lock type, just a different owner, and moreover usually we ask for a session lock on a rel that we already have locked normally. So it doesn't work to say "skip trying fast path if sessionLock" --- we typically won't get that far in the code. We could conceivably make it work if we were willing to forcibly promote an existing fastpath lock to regular when a session lock gets asked for, but that's complication I don't want much, especially since it would go completely untested in normal use. (I verified the claim above that we never take session locks on any fast-path-eligible lock types.) We could still do this if we were willing to actually reject requests for session level locks on fast-path-eligible lock types. At the moment that costs us nothing really. If anyone ever did have a use case, we could consider adding the extra logic to support it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers