Re: pg_locks needs a facelift

On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
> > On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> > Well, there's nothing that says you have to actually refer to locks by
> > name. When I proposed this what I proposed is that the userlock module
> > provide a dedicated means to map a lock name to a lock number, and
> > reserve one of the 'lock spaces' (the 16 bit number) for this use,
> just
> > as one of them is currently reserved for locks based on OID. But I
> also
> > can't think of any reason why lock names need to be persistent, so I
> > imagine you could store a list of lock names in shared memory with no
> > backing storage.
> 
> Well, actually, as currently implemented the userlock module provides 48
> bits of lock space but none of the bits are reserved for
> anything...interface functions which assign the lower 32 bits to oid are
> provided as a convenience.  IIRC userlocks were first implemented in

If I remember the docs correctly, it specifically mentions that one of
the 16 bit values is used for the OID mapping. That value could be 0, I
don't know, but the point is that anyone using userlock would naturally
stay away from that range.

> 1998 when the oid played a larger role, it is now quite rightly
> deprecated and my intention is to remove it from the userlock module.

I wish you wouldn't since http://rrs.decibel.org uses it.

> The new userlocks should be able to take advantage of refinements in the
> locktag structure and provide a full 64 bits to resolve the lock at the
> least.  64 bits is the magic number because it now works quite nicely
> with sequences.  Could you be more specific about how a string based
> user lock system would be implemented?

My thought is to include a lookup table in the module that would
correlate text names to lock numbers. For those who don't care about
performance, they could just aquire and release locks with a function
that accepts a text name. If performance was an issue, they could lookup
the lock number/ID for a text name and store that value. I also don't
see any reason not to set aside a range of numbers as being intended for
general use, and specifying that named locks would never use a number in
that range.

If you're going to go to 64 bit locks I suggest setting aside the range
of 0 to 0x00ff ffff (that is 48 bits, right? :) for backwards
compatability, and also carving out a small chunk for use by other
defined access methods (such as named locks and OIDs). That way if
someone else thinks of an interesting way to refer to locks it can be
added without worrying about colliding with locks used by existing
software.

BTW, the reason I'm so worried about lock number collisions is that the
application I use them in is designed to run in an existing PostgreSQL
database, which could easily be using userlocks of it's own. I want to
do everything possible to ensure I don't conflict with anything else in
the cluster (locks are cluster-wide, right?), so I use the OID of the
function that aquires the lock. But of course that OID could end up
duplicated, so I'd much rather be able to use a named lock which is
almost guaranteed to be unique (unless someone else decides
'rrs.decibel.org: update()' makes a great lock name...)
-- 
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?"