On Fri, Jan 28, 2022 at 6:34 PM Mladen Gogala <gogala.mla...@gmail.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
