Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
