| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_try_advisory_lock is waiting? |
| Date: | 2022-01-29 00:08:14 |
| Message-ID: | 2858894.1643414894@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> writes:
> I tried the following:
> _*1st Session:*_
> mgogala=# begin transaction;
> BEGIN
> mgogala=*# update emp set sal=sal*1 where empno=7934;
> UPDATE 1
> mgogala=*#
> _*2nd Session:*_
> mgogala=# begin transaction;
> BEGIN
> mgogala=*# select pg_try_advisory_lock(0) from (select ename from emp
> where empno=7934 for update) as tbl;
> To my infinite surprise, "pg_advisory_lock" is waiting.
I doubt it. I think the FOR UPDATE in the sub-select is blocked
because the other session has an uncommitted update on the row
it wants to lock. This command won't reach the pg_try_advisory_lock
call until that row lock comes free.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mladen Gogala | 2022-01-29 00:33:55 | Re: pg_try_advisory_lock is waiting? |
| Previous Message | Michael Lewis | 2022-01-28 23:14:40 | Re: pg_try_advisory_lock is waiting? |