Re: pg_locks needs a facelift

FWIW, I've asked previously for a means to name userlocks. The reason
for this is that if you're not locking on some kind of object with an
OID then you're stuck picking some random value and hoping that no one
else using userlock ever picks the same value. If instead there was a
means to name userlocks, it's easy to use a name like "My application:
some thing I want to block on". Putting the 'My application:' in there
pretty much ensures that you won't conflict with anything else, and the
randomness of whatever you call what you're locking on should be plenty
to handle the rest.

On Mon, May 02, 2005 at 01:30:49PM -0400, Tom Lane wrote:
> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> > I don't like the idea of listing user locks with 'tuple' locks for no
> > other reason than this might confuse what user locks are.
>
> Fair enough, although I think that at least one major application of
> user locks would be equivalent to tuple locks. Somebody was asking
> for named user locks in the previous thread, and the easiest way to
> get that is to make a table containing just lock names, and then lock
> on the CTIDs of that table. Since there would be no reason to allow
> UPDATE or DELETE in such a table, the putative instability of CTID
> doesn't really matter.
>
> However, displaying them as object locks certainly works, and you'd have
> to put some intelligence in front of the view anyway about what meaning
> you were assigning to user locks in your installation. So you can
> always cast to whatever you need.
>
> > IMO, this is a problem with the current user lock module...it
> > encourages locking over oid which is a bad practice. A properly
> > implemented user lock system would likely maintain a global sequence
> > shared by all lockable objects, tuple or otherwise.
>
> Certainly the current contrib/userlock code could stand a rewrite.
> Or more likely, addition of new functions --- we should deprecate
> the old ones, but I see no need to remove 'em right away.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
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?"