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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
