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

Reply via email to