Kristian Nielsen via developers <developers@lists.mariadb.org> writes:
I'm thinking it will be rare to have the same value of (undo_no + LENGTH(lock.trx_locks)) for two transactions, which is the only way this code can trigger. But I'm not familiar with the original reason for this piece of the code, that's why I asked.
Ok, now I understand that the TRX_WEIGHT is approximately the number of rows modified + the number of locks held, so it will not be _that_ rare for them to be equal. So I have kept the functionality that all else being equal, the current trx will be preferred over another transaction in the cycle. I assume this is because it's cheaper to roll back the current transaction, than to mark another transaction as the victim, go to sleep, and then wake back up once the other transaction(s) has released the lock waited for? I refined my patch with bitwise operations to keep using a single comparison between weights in the cycle loop. I use the top bit for the thd_deadlock_victim_preference() and the lowest bit to prefer the current transaction over another with same weight. The result is here. If you agree and Andrei also reviews ok, I will use this as the 10.6 version of the 10.4 patch (which won't merge to 10.6). This should fix several sporadic Buildbot failures as well. https://github.com/MariaDB/server/tree/knielsen_bugfix_10.6 https://github.com/MariaDB/server/commit/5216296b2f85290ee5ed760c62e18b075e3... - Kristian.