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
>
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 |