Ok,
With 8.0 out the door, I'd like to reopen discussion re: userlock
contrib. module and propose to get it moved into the core database
sources. This was discussed a bit a few months back but it never made
it officially to the todo list. I'm not sure what the final consensus
was on the shared locks discussion, but it might be a good idea to
consider user locks at the same time (and vise versa), since they might
invoke related changes to the documentation, etc. At the very least,
I'd like to know that if properly documented, userlocks stand a chance
of being upgraded to the core project.
First, a little about the current userlock module:
1. It is GPL. However, the module is nothing more than a couple of
wrappers to the backend functions LockAcquire, LockRelease, etc. and
some documentation. I'm suggesting to recode the wrappers and redo the
documentation as well in the BSD license.
2. userlocks provide a very powerful and high performance method of row
level locking. With a little bit of clever coding, they can do other
tricks...
3. The current system view, pg_locks, does not display enough
information about user locks...I'd suggest either expanding the current
view and/or adding a new view, pg_user_locks (along with new function in
lockfuncs.c)
4. Current user locks implementation is missing (at least 2) important
features...1. ability of superuser to kill a lock owned by another user
(corollary: does lockrelease support this?), and 2. the ability to deal
with the full 48 bit lock as a single datum (new system type?). Would
also be nice to have a lockmode that waits for a lock for a period of
time.
5. Need lots of documentation changes...would like to beef up section
covering lock module, plus better description of runtime setting
'max_locks_per_transation' including a possible rename.
Merlin
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
