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
