On Mon, Sep 18, 2006 at 10:10:32AM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > One problem I see with userlock is that you're asking for lock ID > > conflicts unless you control everything on the system that's using > > userlocks. > > Well, the lock IDs already include the database OID under the hood, > so you only need to control stuff within your database. Beyond that, > yeah, it's your responsibility...
Which is what I'm worried about for the future... that's why I'd like to recommend to users some kind of best practice that allows for a system in the future that doesn't require managing every single lock in the system. I believe recommending that you not use locks with the first int4 above 16k (and whatever the equivalent would be for int8) would be a good way to do that, as it would allow for segregating locks by schema OID. It's important to recommend this now so that people don't write software that will clobber other locks in the future. -- 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
