Re: RE: User locks code
От | Tom Lane |
---|---|
Тема | Re: RE: User locks code |
Дата | |
Msg-id | 1828.998415131@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: User locks code ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>) |
Список | pgsql-hackers |
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes: >> (dunno if the locks would scale to a scenario with hundreds >> of concurrent inserts - how many user locks max?). > 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 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. regards, tom lane
В списке pgsql-hackers по дате отправления: