Re: User locks code

> 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 unlock objects* inside transaction, which is not
>     (and will not be) available with locks held by transactions.
> 
> They are interesting too and proposed implementation will not impact lock
> manager (just additional 4 bytes in LOCKTAG => same size of LOCKTAG
> on machines with 8 bytes alignment).
> 
> > An interesting method would be to allow users to simply avoid locked
> > rows:
> >
> > SELECT * FROM queue FOR UPDATE LIMIT 1 UNLOCKED;
> >
> > Unlocked, return immediately, whatever could be used as a keyword to
> > avoid rows that are locked (skipping over them).
> >
> > For update locks the row of course.  Currently for the above type of
> > thing I issue an ORDER BY random() which avoids common rows enough,
> > the queue agent dies if queries start taking too long (showing it's
> > waiting for other things) and tosses up new copies if it goes a while
> > without waiting at all (showing increased load).
> >
> > --
> > Rod Taylor
> >
> > This message represents the official view of the voices in my head
> >
> > ----- Original Message -----
> > From: "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
> > To: <pgsql-hackers@postgresql.org>
> > Sent: Friday, August 17, 2001 2:48 PM
> > Subject: [HACKERS] User locks code
> >
> >
> > > 1. Just noted this in contrib/userlock/README.user_locks:
> > >
> > > > User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
> > > > Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
> > > >
> > > > This software is distributed under the GNU General Public License
> > > > either version 2, or (at your option) any later version.
> > >
> > > Well, anyone can put code into contrib with whatever license
> > > he/she want but "user locks" package includes interface
> > > functions in contrib *and* changes in our lock manager, ie
> > > changes in backend code. I wonder if backend' part of package
> > > is covered by the same license above? And is it good if yes?
> > >
> > > 2. Not good implementation, imho.
> > >
> > > It's too complex (separate lock method table, etc). Much cleaner
> > > would be implement this feature the same way as transactions
> > > wait other transaction commit/abort: by locking objects in
> > > pseudo table. We could get rid of offnum and lockmethod from
> > > LOCKTAG and add
> > >
> > > struct
> > >
> 
> > > Oid RelId;
> > > Oid ObjId;
> > > } userObjId;
> > >
> > > to objId union of LOCKTAG.
> > >
> > > This way user could lock whatever object he/she want in specified
> > > table and note that we would be able to use table access rights to
> > > control if user allowed to lock objects in table - missed in 1.
> > >
> > > One could object that 1. is good because user locks never wait.
> > > I argue that "never waiting" for lock is same bad as "always
> > waiting".
> > > Someday we'll have time-wait etc features for general lock method
> > > and everybody will be happy -:)
> > >
> > > Comments?
> > >
> > > Vadim
> > > P.S. I could add 2. very fast, no matter if we'll keep 1. or not.
> > >

4. Most important: user locks are retained across transaction, which is  not possible with ordinary locks.

5. User locks semantic is defined entirely by the application and is not  related to rows in the database.

I wrote the user locks code because I needed a method to mark items as
`busy' for very long time to avoid more users modifying the same object
and overwriting each one's changes. This requires two features:
   1.    they must survive transaction boundary. The typical use of userlocks is:
    transaction 1:    select object,user_lock(object);
    ... work on object for long time
    transaction 2: update object,user_unlock(object);
   2.    they must not block if the object is already locked, so that theprogram doesn't freeze and the user simply
knowsit can't use thatobject.
 

When I wrote the code the only way to do this was to add a separate lock
table and use the same machinery of ordinary locks. I agree that the code
is complex and should probably be rewritten.

If you think there is a better way to implement this feature go ahead,
better code is always welcome.

The only problem I have found with user locks is that if a backend crashes
without releasing a lock there is no way to relase it except restarting
the whole postgres (I don't remember exactly why, I forgot the details).

Regarding the licencing of the code, I always release my code under GPL,
which is the licence I prefer, but my code in the backend is obviously
released under the original postgres licence. Since the module is loaded
dynamically and not linked into the backend I don't see a problem here.
If the licence becomes a problem I can easily change it, but I prefer the
GPL if possible.

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: see my www home page         |
+----------------------------------------------------------------------+