From: | Vick Khera <vivek(at)khera(dot)org> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Named advisory locks |
Date: | 2011-04-05 15:49:31 |
Message-ID: | BANLkTinr-Hq+cprOSGfpg8BMXXLqiArz_w@mail.gmail.com |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Selena Deckelmann | 2011-04-05 16:12:18 | Seeking Postgres users, DBAs and developers in areas where we don't have conferences or user groups |
Previous Message | rihad | 2011-04-05 15:33:28 | Re: Named advisory locks |