Re: userlock changes for 8.1/8.2

Speaking of other tricks and things missing; I'd like to see support for
named locks. If you're using locks for something other than row-level
locking, it's awkward at best to have to come up with an OID to identify
your lock with, and even that doesn't guarantee uniqueness. You're also
out of luck if the table you're doing row level locking on doesn't have
OIDs. You also can't do direct OID locking on more than one table in an
application.

I think two different naming facilities would be of use:
1) A namespace for single locks, where each lock has it's own name.
2) A namespace for a set of locks. Another way to look at this would be
a namespace for group IDs.

I realize that this conflicts with the existing userlock implementation,
so it might be necessary to have a second set of locks to support this.

On Mon, Jan 24, 2005 at 01:31:34PM -0500, Merlin Moncure wrote:
> 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
> 

-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"