This PR ports #17500 to master.
#17500 was first planned to be used as the fix for versions <= 8.1, however, the complete fix (#17451) was then still considered too risky. So we decided to also use #17500 as the fix for master as well as 8.5 branch, and the complete fix will be left and may be considered in the future.

After this fix, there may be a little more false posotive / false negative cases in the deadlock detection under lock contention scenarios.

What is changed and how it works?

Issue Number: Close #17394

What's Changed:

lock_manager: Skip updating lock wait info for non-fair-locking requests

This is a simpler and lower-risky fix of the OOM issue #17394 for released branches, as an alternative solution to #17451 .
In this way, for acquire_pessimistic_lock requests without enabling fair locking, the behavior of update_wait_for will be a noop. So that if fair locking is globally disabled, the behavior will be equivalent to versions before 7.0.

This is a simple alternative solution to #17451 .
For non-fair locking scenario, it's confirmed that the problem can be avoided.

Before:

After:

Related changes

• PR to update pingcap/docs/pingcap/docs-cn:
• Need to cherry-pick to the release branch

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Release note

Fix an issue that when frequently updating a row while many transaction is waiting on the lock, it might sometimes cause TiKV OOM