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(at)SECTORBASE(dot)COM>
> To: <pgsql-hackers(at)postgresql(dot)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(at)cs(dot)unitn(dot)it>
> > > Copyright (C) 1999, Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)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.
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> > message can get through to the mailing list cleanly
> >
>