RE: User locks code

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'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: User locks code
Date: 2001-08-20 16:39:42
Message-ID: 3705826352029646A3E91C53F7189E32016743@sectorbase2.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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/place
key in that table, than construct LOCKTAG and call
LockAcquire.
Possible syntax:

LOCK TABLE relation IN {SHARE | EXCLUSIVE} MODE
ON KEY user-string [FOR TRANSACTION | FOR SESSION];

UNLOCK (RELEASE?) TABLE relation {SHARE | EXCLUSIVE} LOCK
ON KEY user-string;

(or just some built-in functions).

> 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 -:))

So, in your application you would first lock a key in excl mode
(for duration of transaction), than try to select and insert unless
found? (Note that this will not work with serializable isolevel.)

Comments?

Vadim

Browse pgsql-hackers by date

  From Date Subject
Next Message Nicolas Verger 2001-08-20 16:40:32 RE: Select parser at runtime ....
Previous Message Mikhail Terekhov 2001-08-20 16:31:49 Re: [HACKERS] Re: WIN32 errno patch