RE: RE: User locks code

> > I don't see problem here - just a few bytes in shmem for
> > key. Auxiliary table would keep refcounters for keys.
>
> I think that running out of shmem *would* be a problem for such a
> facility. We have a hard enough time now sizing the lock table for

Auxiliary table would have fixed size and so no new keys would be
added if no space. I don't see problem with default 8Kb aux table,
do you?

> system locks, even though they use fixed-size keys and the system as
> a whole is designed to ensure that not too many locks will be held
> simultaneously. (For example, SELECT FOR UPDATE doesn't try to use
> per-tuple locks.) Earlier in this thread, someone proposed using
> user locks as a substitute for SELECT FOR UPDATE. I can guarantee
> you that that someone will run out of shared memory before long,
> if the userlock table resides in shared memory.

How is proposed "key locking" is different from user locks we
have right now? Anyone can try to acquire many-many user locks.

Vadim