Re: Named advisory locks - Mailing list pgsql-general

From rihad
Subject Re: Named advisory locks
Date
Msg-id 4D9B6431.6000708@mail.ru
Whole thread Raw
In response to Re: Named advisory locks  (Ben Chobot <bench@silentmedia.com>)
Responses Re: Named advisory locks
List 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 by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language..
Next
From: Jeff Davis
Date:
Subject: Re: Out of memory