Re: 8.2 beta blockers

From: "Jim C(dot) Nasby" <jimn(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.2 beta blockers
Date: 2006-09-18 17:54:17
Message-ID: 20060918175417.GB47167@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 18, 2006 at 10:10:32AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jimn(at)enterprisedb(dot)com> 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 jimn(at)enterprisedb(dot)com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-09-18 17:56:35 Re: Interesting CREATE TABLE AS misbehavior
Previous Message Gevik Babakhani 2006-09-18 17:53:56 An Idea for OID conflicts