Re: Named advisory locks - Mailing list pgsql-general

From Vick Khera
Subject Re: Named advisory locks
Date
Msg-id BANLkTinr-Hq+cprOSGfpg8BMXXLqiArz_w@mail.gmail.com
Whole thread Raw
In response to Re: Named advisory locks  (rihad <rihad@mail.ru>)
List pgsql-general
On Tue, Apr 5, 2011 at 10:35 AM, rihad <rihad@mail.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.

pgsql-general by date:

Previous
From: rihad
Date:
Subject: Re: Named advisory locks
Next
From: Selena Deckelmann
Date:
Subject: Seeking Postgres users, DBAs and developers in areas where we don't have conferences or user groups