On Fri, Sep 22, 2006 at 01:42:48PM -0400, Merlin Moncure wrote: > On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> 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.
Ahh, ok, I didn't realize that the total lock space was larger than what's being exposed today. That means we can easily add that stuff in the future and not break anything, which is all I was looking for. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
