public inbox for [email protected]
help / color / mirror / Atom feedFrom: Achilleas Mantzios <[email protected]>
To: [email protected]
Subject: Re: Strange deadlock with object/target of lock : transaction
Date: Mon, 25 Aug 2025 15:40:06 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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.
>>>
>>>
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Strange deadlock with object/target of lock : transaction
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox