Re: RE: User locks code

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

In response to

Browse pgsql-hackers by date

  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