From: | rihad <rihad(at)mail(dot)ru> |
---|---|
To: | Ben Chobot <bench(at)silentmedia(dot)com> |
Cc: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Named advisory locks |
Date: | 2011-04-05 15:33:28 |
Message-ID: | 4D9B3648.1020408@mail.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Vick Khera | 2011-04-05 15:49:31 | Re: Named advisory locks |
Previous Message | Ben Chobot | 2011-04-05 15:29:25 | Re: Named advisory locks |