On 9/22/06, Jim C. Nasby <jim@nasby.net> wrote:
> I'm not asking for a defined solution to how to support multiple
> different users of locks within the same database. I just want us to set
> aside (as in, recommend they not be used) some set of numbers so that in
> the future we could recommend a means of picking lock numbers that will
> avoid collisions.
you pretty much already have this, current advisory lock exposes 64
bits of locktag storage. there is 112 bits (3 int4 and 1 int2)
available. this is since 8.1 when locktag was reorganized. I was
actually going to suggest esposing these fields but had second
thoughts due to future proofing issues.
note i am not arguing that advisory lock should not be expanded in the
future or do string maps, just that at present talking about reserved
ranges would just confuse people since the lock space is intentionally
generic.
merlin