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.


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
postedAug 21, '01 at 5:54p
activeAug 21, '01 at 5:54p

1 user in discussion

Mikheev, Vadim: 1 post



site design / logo © 2021 Grokbase