Re: Named advisory locks
От | rihad |
---|---|
Тема | Re: Named advisory locks |
Дата | |
Msg-id | 4D9B3648.1020408@mail.ru обсуждение исходный текст |
Ответ на | Re: Named advisory locks (Ben Chobot <bench@silentmedia.com>) |
Список | pgsql-general |
On 04/05/2011 08:29 PM, Ben Chobot wrote: > > 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 cannot safely reuse >> them. Aren't advisory lock ID's unique across the whole server? The >> sole purpose of the string ID is to be able to supply an initial >> namespace prefix ("foo.NNN") so NNN wouldn't clash in different >> subsystems of the app. MySQL is pretty convenient in this regard. >> Now I think it would be easier for me to work around this Postgres >> limitation by simply LOCKing on some table (maybe one created >> specifically as something to lock on to) instead of using >> pg_advisory_lock explicitly. > > Simply locking tables might be easy, but probably won't be optimal. > Why are you using advisory locks at all? They certainly have their > place, but they can also be an overused crutch, especially for people > less familiar with MVCC. . > We're using advisory locks to limit access to an external shared resource.
В списке pgsql-general по дате отправления: