On 25/8/25 17:58, Adrian Klaver wrote:
> On 8/25/25 07:40, Achilleas Mantzios wrote:
>> 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
>
>> 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.
>
> For folks that run across this thread what was the issue?
Inconsistent order of updates. The two pieces of code , the update piece
and the insert piece, used inconsistent order of updates. However this
could not be manifested with one xaction of the update-type and one of
the insert-type, there had to be more than one transactions of the
update-type doing the same update (usually caused by users hitting the
reload button after 1 or 2 seconds). I can easily prepare a test case,
schema, data, commands for anyone interested.
