Re: User locks code

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.
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>