Hi Adrian
On 8/14/25 15:39, Adrian Klaver wrote:
On 8/14/25 00:07, Achilleas Mantzios wrote:
Hi All
We've been hit by a weird deadlock which it took me some days to
isolate and replicate. It does not have to do with order of updates
or any explicit TABLE-level locking, the objects/targets of the
deadlock in question are transactions.
First off, I maybe wrong with the above conclusion, I noticed that even
in the common deadlock scenario (xact A updating object 1 and then 2,
while xact B updating 2 and then 1) the message is again the same , i.e.
Process <pid1> waits for ShareLock on transaction <xactB>; blocked by
process <pid2>.
Process <pid2> waits for ShareLock on transaction <xactA>; blocked by
process <pid1>.
while updating tuple ()...
Also I should have mentioned that it takes at least three transactions
as in the example to make the deadlock happen. At least two of the
"UPDATE" style and one of the "INSERT" style.
I have some questions:
1) Did this work in versions prior to 18?
No, our production is on 16.9 and this is where I got the issue.
2) The test case you ran was done on 18beta1, are you planning to test
on the just released 18beta3?
I must upgrade, but I don't think anything will change, this behavior
seems consistent at least across 16->18beta1
