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

On 8/20/25 14:59, Achilleas Mantzios wrote:

> On 8/14/25 16:01, Achilleas Mantzios wrote:
>
>> 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
> Hi, I just tested with 18beta3, as expected, no change at all, I still 
> get the deadlock.

Hi I reproduced without the triggers, I understood the problem, I 
believe the system's behavior is the intended, I am sorry for the false 
alarm. The thing is that it takes >=3 transactions to happen . That was 
the tricky part, up to now in all cases of deadlocks we had two 
transactions involved, this one needed three or more.

>>>
>>>