Re: advisory locks and permissions

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: AgentM <agentm(at)themactionfaction(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: advisory locks and permissions
Date: 2006-09-22 17:12:06
Message-ID: 20060922171206.GL28987@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 22, 2006 at 12:56:37PM -0400, Merlin Moncure wrote:
> On 9/22/06, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
> >This is why I suggested we set aside some range of numbers that should
> >not be used. Doing so would allow adding a better-managed
> >numbering/naming scheme in the future.
>
> 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.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2006-09-22 17:14:28 Re: 8.3 Development Cycle
Previous Message Bruno Wolff III 2006-09-22 16:58:04 Re: Getting a move on for 8.2 beta