From: | rihad <rihad(at)mail(dot)ru> |
---|---|
To: | Vick Khera <vivek(at)khera(dot)org> |
Cc: | pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Named advisory locks |
Date: | 2011-04-05 18:49:21 |
Message-ID: | 4D9B6431.6000708@mail.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2011-04-05 19:06:50 | Re: Out of memory |
Previous Message | Merlin Moncure | 2011-04-05 18:26:48 | Re: ..horribly documented, inefficient, user-hostile, impossible to maintain interpreted language.. |