On Mon, 2012-04-09 at 16:11 -0400, Robert Haas wrote: > > I wonder though whether > > you actually need a *count*. What if it were just a flag saying "do not > > take any fast path locks on this object", and once set it didn't get > > unset until there were no locks left at all on that object? > > I think if you read the above-referenced section of the README you'll > be deconfused.
My understanding: The basic reason for the count is that we need to preserve the information that a strong lock is being acquired between the time it's put in FastPathStrongRelationLocks and the time it actually acquires the lock in the lock manager. By definition, the lock manager doesn't know about it yet (so we can't use a simple rule like "there are no locks on the object so we can unset the flag"). Therefore, the backend must indicate whether it's in this code path or not; meaning that it needs to do something on the error path (in this case, decrement the count). That was the source of this bug. There may be a way around this problem, but nothing occurs to me right now. Regards, Jeff Davis PS: Oops, I missed this bug in the review, too. PPS: In the README, FastPathStrongRelationLocks is referred to as FastPathStrongLocks. Worth a quick update for easier symbol searching. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers