From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
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:21:57 |
Message-ID: | b42b73150609221021x52c73f48m5e6c81b90445c3f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/22/06, Jim C. Nasby <jim(at)nasby(dot)net> 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.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2006-09-22 17:24:19 | Re: Is there any utility to update the table whenever text file gets changed? |
Previous Message | Jim C. Nasby | 2006-09-22 17:16:40 | Re: Getting a move on for 8.2 beta |