Re: bug in fast-path locking

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.