> > 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
"Mikheev, Vadim" <[EMAIL PROTECTED]> 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 runnin
> 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
k
At 09:39 AM 20-08-2001 -0700, Mikheev, Vadim wrote:
>> If it does then one of the things I'd use it for is to insert
>> unique data without having to lock the table or rollback on
>> failed insert (unique index still kept as a guarantee).
>
>(Classic example how could be used SAVEPOINTs -:))
I gu
> Would your suggested implementation allow locking on an
> arbitrary string?
Well, placing string in LOCKTAG is not good so we could
create auxilary hash table in shmem to keep such strings
and use string' address as part of LOCKTAG. New function
(LockRelationKey?) in lmgr.c would first find/pla
At 11:20 AM 8/19/01 -0700, Vadim Mikheev wrote:
>Well, ability to lock only unlocked rows in select for update is useful,
>of course. But uniq features of user'locks are:
>
>1. They don't interfere with normal locks hold by session/transaction.
>2. Share lock is available.
>3. User can lock *and u
