Re: advisory locks and permissions

On Sep 22, 2006, at 12:46 , Merlin Moncure wrote:

> On 9/22/06, AgentM <agentm@themactionfaction.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