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