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.