From: | AgentM <agentm(at)themactionfaction(dot)com> |
---|---|
To: | postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: advisory locks and permissions |
Date: | 2006-09-22 16:54:01 |
Message-ID: | F8AA5CB6-4DE2-44F6-B82C-23398D46844A@themactionfaction.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sep 22, 2006, at 12:46 , Merlin Moncure wrote:
> On 9/22/06, AgentM <agentm(at)themactionfaction(dot)com> wrote:
>> I would be more worried about accidental collisions between
>> applications. The lock ranges will now need to be in their respective
>
> i dont think this argument has merit because the lock is scoped to the
> current database. this would only be a problem if two applications
> used the same database...not likely.
Since we have schemas, I have several applications running in one
database- sometimes several versions of the same application. This
makes it easier to shuffle data around.
>> application's configuration file in case of collision with another
>> app once developers really start using locks for IPC. Ideally, the
>> user-level lock functions would take strings instead of integers and
>> hash them appropriately, no? Otherwise, someone will end up
>> maintaining a registry of lock numbers in use. LISTEN doesn't use
>> integers.
>
> application can translate the locks to strings via a very simple
> translation table. there is no downside to this besides a index
> lookup on a small table, which is more or less what the listen/notify
> does internally.
>
> advisory locks work off of the internal lock system which is an
> integer only system. the whole point is to get at these locks while
> bypassing the transaction system. you are suggesting something which
> does not fit into the current lock system.
I didn't suggest using lookup tables; I suggested that the lock
functions should perform the string hashing itself- the applications
will write wrappers for this anyway to prevent collisions or they
will have to provide some configuration element to change the lock
range in case of collision- which will be extraordinarily difficult
to debug in the first place.
-M
From | Date | Subject | |
---|---|---|---|
Next Message | J-Pro | 2006-09-22 16:55:16 | silent install: silent error (even using the manual) |
Previous Message | Merlin Moncure | 2006-09-22 16:46:27 | Re: advisory locks and permissions |