Re: Named advisory locks
От | rihad |
---|---|
Тема | Re: Named advisory locks |
Дата | |
Msg-id | 4D9B6431.6000708@mail.ru обсуждение исходный текст |
Ответ на | Re: Named advisory locks (Ben Chobot <bench@silentmedia.com>) |
Ответы |
Re: Named advisory locks
|
Список | pgsql-general |
> On Tue, Apr 5, 2011 at 10:35 AM, rihad <rihad(at)mail(dot)ru> 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. > > > so if you have a namespace problem, solve that. the range of integers is > quite large. just assign a range to each application so they don't clash. Can't do that, because I'm simply using some table's serial value as the lock ID, which is itself a bigint. The workaround of LOCKing on a table looks fine to me.
В списке pgsql-general по дате отправления: