Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock

From: Cherio <cherio(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock
Date: 2021-08-11 15:39:29
Message-ID: CAKHqFk+h5x8aFA0oxoqTYxzT+pj55o_i88cHK1+gV4wcWLp6HA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I can not reproduce it any more.
There is a chance there were more forces at play when I was getting the
lock warning message.
Please forgive the disturbance.

On Wed, Aug 11, 2021 at 9:50 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > Function "pg_try_advisory_xact_lock" triggers a WARNING message when the
> > lock is already owned by someone else.
>
> I failed to duplicate this behavior. I did this in session A:
>
> regression=# begin;
> BEGIN
> regression=*# select pg_try_advisory_xact_lock(1);
> pg_try_advisory_xact_lock
> ---------------------------
> t
> (1 row)
>
> then this in session B:
>
> regression=# select pg_try_advisory_xact_lock(1);
> pg_try_advisory_xact_lock
> ---------------------------
> f
> (1 row)
>
> No warning...
>
> regards, tom lane
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-08-11 16:38:15 BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows
Previous Message Tom Lane 2021-08-11 13:50:16 Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock