Re: Advisory locks seem rather broken

Robert Haas <robertmhaas(at)gmail(dot)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