userlock changes for 8.1/8.2

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

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(at)decibel(dot)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?"

"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> Speaking of other tricks and things missing; I'd like to see support for
> named locks.

[ yawn... ] Create a table with a "name" column, put some rows in it,
lock the rows.

regards, tom lane

On Mon, Jan 24, 2005 at 10:43:40PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> > Speaking of other tricks and things missing; I'd like to see support for
> > named locks.
>
> [ yawn... ] Create a table with a "name" column, put some rows in it,
> lock the rows.

What would guarantee that the OIDs of those rows don't conflict with
some other OIDs in the system?

BTW, this becomes a real issue if you're trying to write code that is
meant to be incorporated into other PostgreSQL applications, which might
also be using user_lock. Having a text-based means to identify locks
greatly reduces the odds of conflicting with a userlock being used by an
existing application.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)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?"