Skip to content
/ server Public

Comments

MDEV-37977 InnoDB deadlock report incorrectly reports rolled back transaction number#4679

Open
arcivanov wants to merge 1 commit intoMariaDB:10.11from
arcivanov:MDEV-37977
Open

MDEV-37977 InnoDB deadlock report incorrectly reports rolled back transaction number#4679
arcivanov wants to merge 1 commit intoMariaDB:10.11from
arcivanov:MDEV-37977

Conversation

@arcivanov
Copy link
Contributor

The "WE ROLL BACK TRANSACTION (N)" message in the deadlock report referred to the wrong transaction number. The victim selection loop and the display loop in Deadlock::report() traversed the cycle in the same order (cycle->wait_trx, ..., cycle) but used misaligned position numbering:

  • Victim selection initialized victim = cycle at position 1 before the loop, then started iterating from cycle->wait_trx at position 2.
  • Display loop started from cycle->wait_trx at label (1), with cycle displayed last at label (N).

This caused victim_pos to be off by one relative to the displayed transaction labels.

Fix: restructure the victim selection loop to start with l=0 and victim=nullptr, letting the loop handle all transactions uniformly. The first iteration unconditionally picks cycle->wait_trx as the initial victim at position 1, matching the display loop. The thd_deadlock_victim_preference() call is guarded with a victim != nullptr check to skip it on the first iteration (where no prior victim exists to compare against).

…nsaction number

The "WE ROLL BACK TRANSACTION (N)" message in the deadlock report
referred to the wrong transaction number. The victim selection loop
and the display loop in `Deadlock::report()` traversed the cycle in
the same order (`cycle->wait_trx, ..., cycle`) but used misaligned
position numbering:

- **Victim selection** initialized `victim = cycle` at position 1
  *before* the loop, then started iterating from `cycle->wait_trx`
  at position 2.
- **Display loop** started from `cycle->wait_trx` at label `(1)`,
  with `cycle` displayed last at label `(N)`.

This caused `victim_pos` to be off by one relative to the displayed
transaction labels.

Fix: restructure the victim selection loop to start with `l=0` and
`victim=nullptr`, letting the loop handle all transactions uniformly.
The first iteration unconditionally picks `cycle->wait_trx` as the
initial victim at position 1, matching the display loop. The
`thd_deadlock_victim_preference()` call is guarded with a
`victim != nullptr` check to skip it on the first iteration (where
no prior victim exists to compare against).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant