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.