Re: Another bug introduced by fastpath patch

I wrote:
> 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.

Nope, that *still* doesn't work, because in non-allLocks mode the main
loop won't clear any locks that have been promoted from fastpath to
regular. Sigh. For the moment I'm proposing that we just re-fetch
the list header after acquiring the lock. The attached patch is slightly
more verbose than that, because I took the opportunity to reformulate the
while() loop as a for() loop and thereby eliminate some goto's.

regards, tom lane