Re: BUG #13920: pg_try_advisory_xact_lock bigint trouble

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "mtakvel(at)gmail(dot)com" <mtakvel(at)gmail(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13920: pg_try_advisory_xact_lock bigint trouble
Date: 2016-02-09 01:52:49
Message-ID: CAKFQuwZi+Xx0GF77XzSr9SO1FRFS6cOo9r2-MCP_kVnbF0kbdg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Friday, February 5, 2016, <mtakvel(at)gmail(dot)com> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 13920
> Logged by: Valeriy
> Email address: mtakvel(at)gmail(dot)com <javascript:;>
> PostgreSQL version: 9.5.0
> Operating system: Ubuntu
> Description:
>
> Hello, I have few high load big tables. My logic calls
> pg_try_advisory_xact_lock(bitint) for locking row in current table. As I
> see
> with bigint param pg_try_advisory_xact_lock lock same ids for all my
> tables.
> Insthead lock only row in one current table. Looks like this is bug and
> will
> be cool if you fix it.
>
>
Likely working as designed. If you wish to provide an example of what you
are doing we can probably explain your misunderstanding. Basically,
though, there is nothing about the ID you pass to the advisory lock
functions that cause them to be associated with a table. The ID is simply
a number. You should try the two-key version and associate the first key
with the table (probably oid) and the second with the row on that table.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2016-02-09 02:00:52 Re: BUG #13934: wrong result of split_part with char value
Previous Message Peter Geoghegan 2016-02-09 01:45:55 Re: BUG #13936: jsonb_object() -> ERROR: unknown type of jsonb container