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 [EMAIL PROTECTED] 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
