| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_try_advisory_lock is waiting? |
| Date: | 2022-01-31 20:36:55 |
| Message-ID: | CAHyXU0zWSgL16yqJroJHA5djr=ZwyqM94=GoOFJ2MFgzhY1_9A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, Jan 28, 2022 at 6:34 PM Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com> wrote:
>
> On 1/28/22 19:08, Tom Lane wrote:
>
> 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.
>
> Yes, I figured it out, but pg_try_advisory_lock returned TRUE even without "FOR UPDATE" clause in the subquery. Shouldn't it return false because it can't lock the row until the uncommitted update finishes?
advisory locks and row locks are completely distinct and separate.
It's also not a good idea to make any assumptions on order of
operations as to which lock is acquired first using subqueries in that
fashion.
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yudianto Prasetyo | 2022-01-31 22:17:50 | Re: what is the solution like oracle DB's datafile |
| Previous Message | Ketan Popat | 2022-01-31 08:07:02 | Can one call pg_total_relation_size over foreign data wrapper? |