On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote: > On 9/22/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > >On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote: > >> the whole point about advisory locks is that the provided lock space > >> is unmanaged. for example, in the ISAM system I wrote which hooked > >> into the acucobol virtual file system interface, I used a global > >> sequence for row level pessimistic locking but reserved the 48th bit > >> for table level locks. This system was extremely effective. on the > >> current system I'm working on I use them to lock sequence oid's plus a > >> high bit indicator for what i am doing. in short, advisory locks are > >> application-defined in concept. > > > >Yes, but if you get two pieces of code written by different people using > >them in the same database, you can get hosed. As PostgreSQL becomes more > >popular and more people start developing software for it, this is more > >likely to occur. > > imo, that is no more or less likely than having two pieces of code > store the same table in the same database. I think what you are > describing would only be a concern if the locks were shared across > databases, however this is not the case. the purpose of advisory > locks is to be 'appplication-defined'. how the application is written > is not part of that concept. we are simply granting the ability to > create a mutex with a number for a name, that is all.
Ok, here's a real-world example. RRS (http://rrs.decibel.org) will make use of userlocks if available. RRS by itself isn't very interesting at all; you'd want to use it with something else. Because there's no standard at all for carving up the numbers, I did the best I could by using the OID of one of my functions, because at least back then there was standard OID support. I'm not sure if that even made it into the current version. Using named locks is possibly overkill, but it would be good to at least set aside some chunk of numbers so that it can be done. Likewise I suggested setting aside OIDs above 10k (or whatever a normal database starts numbering at) so that you could at least do per-schema numbering. 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. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match