I noticed the following in some of our code today:
select ... ... for update of a, b;
Inasmuch as the cardinal rule for avoiding deadlocks is to acquire
locks in a consistent order, should such a construction be avoided
in favor of two separate "select ... for update" statements so that
the o
Once upon a time, I put a question regarding deadlocks to the group,
and Tom Lane immediately answered with this:
>The guy waiting on the tuple-specific lock is second in
>line to actually mung the tuple. Whoever is first in line behind the
>current tenant will be blocked trying to acquire ShareL
Once upon a time, I put a question regarding deadlocks to the group,
and Tom Lane immediately answered with this:
>The guy waiting on the tuple-specific lock is second in
>line to actually mung the tuple. Whoever is first in line behind the
>current tenant will be blocked trying to acquire Share
I am trying to locate the source of some deadlocks that have started
cropping up recently, with little success, and I have a question regarding
the message that accompanies them.
The message my application gets is like this:
Process 244 waits for ShareLock on transaction 39523645; blocked by
proc
