Re: Strange deadlock with object/target of lock : transaction

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
>
>