MDEV-40427 lock_move_reorganize_page() early exit check is useful onl…

[iMineLink]

…y with lock elision

After MDEV-40128, the early exit check in lock_move_reorganize_page() is useful only with lock elision support.
This is because, when lock elision is not supported, TMLockGuard falls back to behave like LockGuard.
The same check would be done using LockGuard later, in any case. Hence, the early exit check can be skipped when lock elision is not supported.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[gemini-code-assist]

Code Review

This pull request introduces a fast path optimization in lock_move_reorganize_page within storage/innobase/lock/lock0lock.cc by checking have_transactional_memory before acquiring a TMLockGuard. This avoids unnecessary lock guard creation when transactional memory is not available. There are no review comments, and I have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[Copilot]

Pull request overview

This PR (MDEV-40427) refines lock_move_reorganize_page()’s early-exit “fast path” so it only runs when transactional memory / lock elision is available, avoiding redundant locking work when elision is not supported (per the behavior change after MDEV-40128).

Changes:

• Gate the early-exit TMLockGuard check behind have_transactional_memory.
• Leave the existing LockGuard-based path unchanged for the general case.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.