Re: Advisory locks seem rather broken

Robert Haas <robertmhaas@gmail.com> writes:
> In 9.1, we just did this:

>                 if (locallock->proclock == NULL || locallock->lock == NULL)
>                 {
>                         /*
>                          * We must've run out of shared memory while
> trying to set up this
>                          * lock.  Just forget the local entry.
>                          */
>                         Assert(locallock->nLocks == 0);
>                         RemoveLocalLock(locallock);
>                         continue;
>                 }

> ...and I just shoved the new logic into that stanza without thinking
> hard enough about what order to do things in.

Right.  The other thing that was bothering me about that was that it's
not clear now how to tell a broken locallock entry (which is what this
logic originally intended to clean up) from a fastpath one.  Perhaps
it'd be a good idea to add a "valid" flag?  And while I'm wondering
about such things, what happens when it's necessary to convert a
fastpath lock to a regular one, but there's no room in shared memory
for more lock objects?
        regards, tom lane