> yep:
> lock "tablename.colname.val=1"
> select count(*) from tablename where colname=1
> If no rows, insert, else update.
> (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.

> Why wouldn't it work with serializable isolevel?

Because of selects see old database snapshot and so you
wouldn't see key inserted+committed by concurrent tx.

Vadim
 

Tue, 21 Aug 2001 09:56:19 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: User locks code
"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

Tue, 21 Aug 2001 13:32:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: RE: User locks code 