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.
