Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock - Mailing list pgsql-bugs

From Cherio
Subject Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock
Date
Msg-id CAKHqFk+h5x8aFA0oxoqTYxzT+pj55o_i88cHK1+gV4wcWLp6HA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@sss.pgh.pa.us> wrote:
PG Bug reporting form <noreply@postgresql.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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock
Next
From: PG Bug reporting form
Date:
Subject: BUG #17141: SELECT LIMIT WITH TIES FOR UPDATE SKIP LOCKED returns wrong number of rows