Re: advisory locks and permissions

Поиск
Список
Период
Сортировка
Искать
От
AgentM
Тема
Re: advisory locks and permissions
Дата
Msg-id
D9E67DE3-08D2-46B3-9C98-3350CAD68A1D@themactionfaction.com
Список
Дерево обсуждения
advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions "Jim C. Nasby" <jim@nasby.net>
Re: advisory locks and permissions Dimitri Fontaine <dim@dalibo.com>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions Josh Berkus <josh@agliodbs.com>
Re: advisory locks and permissions Bruce Momjian <bruce@momjian.us>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions Stephen Frost <sfrost@snowman.net>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions Stephen Frost <sfrost@snowman.net>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions Bruce Momjian <bruce@momjian.us>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions Bruce Momjian <bruce@momjian.us>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions Bruce Momjian <bruce@momjian.us>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions Bruce Momjian <bruce@momjian.us>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions "Joshua D. Drake" <jd@commandprompt.com>
Re: advisory locks and permissions AgentM <agentm@themactionfaction.com>
Re: advisory locks and permissions "Jim C. Nasby" <jim@nasby.net>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions "Jim C. Nasby" <jim@nasby.net>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions "Jim C. Nasby" <jim@nasby.net>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions "Jim C. Nasby" <jim@nasby.net>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions Tom Lane <tgl@sss.pgh.pa.us>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions "Merlin Moncure" <mmoncure@gmail.com>
Re: advisory locks and permissions AgentM <agentm@themactionfaction.com>
Re: advisory locks and permissions Kevin Brown <kevin@sysexperts.com>
Re: advisory locks and permissions Jeremy Drake <pgsql@jdrake.com>

On Sep 22, 2006, at 14:11 , Jim C. Nasby wrote:

> On Fri, Sep 22, 2006 at 01:21:57PM -0400, Merlin Moncure wrote:
>> On 9/22/06, Jim C. Nasby  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.
>
> Except you can put tables (and pretty much all your other objects)  
> in a
> schema, one that's presumably named after your application. That  
> greatly
> removes the odds of conficts.

Indeed. In our development environment, we store development,  
integration, and testing schemas in the same database. This makes it  
trivial to move testing data to development, for example.

If I want to use these locks, it seems I will have to hard-code some  
offset into each app or hash the schema name and use that as an  
offset :( In any case, I can't imagine the "wtf?" nightmares an  
accidental collision would induce.

-M


В списке pgsql-hackers по дате отправления
От: Peter Eisentraut
Дата:
От: Andrew Sullivan
Дата:
FAQ