From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'Lincoln Yeoh'" <lyeoh(at)pop(dot)jaring(dot)my>, Rod Taylor <rod(dot)taylor(at)inquent(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RE: User locks code |
Date: | 2001-08-21 17:32:11 |
Message-ID: | 1828.998415131@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2001-08-21 17:37:47 | Re: Link to bug webpage / Bugzilla? |
Previous Message | Lamar Owen | 2001-08-21 17:30:44 | Re: Link to bug webpage |