> 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
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.

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?


Merlin


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

"Jim C. Nasby" <decibel@decibel.org> writes:
> On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote:
>> 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.

Don't worry, I'll veto any immediate removal of functionality ;-)

The correct way to handle this is to add some better userlock
functionality and deprecate what's there. We can remove the crufty
stuff in a release or three after it's been officially deprecated
.... but there is no reason to remove it immediately. It won't conflict
with a better version, just exist alongside.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

On Tue, May 03, 2005 at 11:43:41PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > I wish you wouldn't since http://rrs.decibel.org uses it.
>
> Don't worry, I'll veto any immediate removal of functionality ;-)

Yes, but will core (or worse, that Bruce guy) over-ride your veto? ;P

> The correct way to handle this is to add some better userlock
> functionality and deprecate what's there. We can remove the crufty
> stuff in a release or three after it's been officially deprecated
> ... but there is no reason to remove it immediately. It won't conflict
> with a better version, just exist alongside.

Hopefully by then I'll have come up with a reason not to support
pre-8.whenever_userlock_is_improved.
--
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?"

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org