Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MDEV-33935 fix deadlock counter #3264

Open
wants to merge 1 commit into
base: 10.6
Choose a base branch
from
Open

Conversation

YVEF
Copy link

@YVEF YVEF commented May 16, 2024

  • The Jira issue number for this PR is: MDEV-33935

Description

Fixed deadlock counter incrementing on every call to cycle finding that was used multiple times during the deadlock detection.

Release Notes

How can this PR be tested?

./mtr mdev-33935

Basing the PR against the correct MariaDB version

  • This is a new feature and the PR is based against the latest MariaDB development branch.
  • This is a bug fix and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

  • I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
  • For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

@YVEF YVEF force-pushed the 10.6-mdev-39935 branch 3 times, most recently from 0ba7ff5 to e3af139 Compare May 17, 2024 10:16
@YVEF YVEF marked this pull request as draft May 17, 2024 10:59
@YVEF YVEF force-pushed the 10.6-mdev-39935 branch 2 times, most recently from 6d488f3 to 625d450 Compare May 23, 2024 20:49
@YVEF YVEF marked this pull request as ready for review May 24, 2024 20:02
Copy link
Contributor

@dr-m dr-m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contribution!

The commit message does not currently explain what is wrong. The MDEV-33935 Description does. I think that it would be better to make source code changes a little more self-contained, not forcing the Jira to be accessed for understanding the problem.

Comment on lines +320 to +330
/** Detect deadlock using @ref Deadlock::find_cycle function facility.
@param trx Transaction that is waiting for another transaction
@return a transaction that is part of a cycle, otherwise nullptr
@note the function is not fully idempotent, each call increments a counter */
static inline trx_t *detect_deadlock(trx_t *trx)
{
trx_t *res= nullptr;
if ((res = find_cycle(trx)) != nullptr)
lock_sys.deadlocks++;

return res;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of adding this function and adjusting both callers of Deadlock::find_cycle(), it would seem that we can move the lock_sys.deadlocks++ to the beginning of Deadlock::report().

Comment on lines +1 to +2
--source include/have_innodb.inc
--source include/have_debug_sync.inc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add also include/have_debug.inc so that the test can be skipped more quickly on a non-debug build.

Even better would be to write this test without DEBUG_SYNC instrumentation, so that it could run on all target architectures. We only have a few debug instrumented builds, not covering all platforms.

There already exists a test innodb.deadlock_detect. Could you extend it so that it demonstrates the problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants