Re: Named advisory locks

Поиск
Список
Период
Сортировка
От Ben Chobot
Тема Re: Named advisory locks
Дата
Msg-id BD4B330D-ACCF-4FDC-834A-5A6618D20A3D@silentmedia.com
обсуждение исходный текст
Ответ на Re: Named advisory locks  (rihad <rihad@mail.ru>)
Ответы Re: Named advisory locks  (rihad <rihad@mail.ru>)
Re: Named advisory locks  (rihad <rihad@mail.ru>)
Список pgsql-general
On Apr 5, 2011, at 7:35 AM, rihad wrote:

> No, what I meant was that we're already using ints for a different purpose in another app on the same server, so I
cannotsafely reuse them. Aren't advisory lock ID's unique across the whole server? The sole purpose of the string ID is
tobe able to supply an initial namespace prefix ("foo.NNN") so NNN wouldn't clash in different subsystems of the app.
MySQLis pretty convenient in this regard. Now I think it would be easier for me to work around this Postgres limitation
bysimply LOCKing on some table (maybe one created specifically as something to lock on to) instead of using
pg_advisory_lockexplicitly. 

Simply locking tables might be easy, but probably won't be optimal. Why are you using advisory locks at all? They
certainlyhave their place, but they can also be an overused crutch, especially for people less familiar with MVCC. 

В списке pgsql-general по дате отправления:

Предыдущее
От: Ray Stell
Дата:
Сообщение: Re: schema access privs
Следующее
От: rihad
Дата:
Сообщение: Re: Named advisory locks