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

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