Re: Named advisory locks

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.

In response to

Responses

Browse pgsql-general by date

  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..