Re: Named advisory locks

From: Ben Chobot <bench(at)silentmedia(dot)com>
To: rihad <rihad(at)mail(dot)ru>
Cc: pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Named advisory locks
Date: 2011-04-05 15:29:25
Message-ID: BD4B330D-ACCF-4FDC-834A-5A6618D20A3D@silentmedia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message rihad 2011-04-05 15:33:28 Re: Named advisory locks
Previous Message Ray Stell 2011-04-05 15:26:49 Re: schema access privs