MDEV-25964: Unexpected bypass of lock#5257
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses an issue where handler errors (such as lock wait timeouts) returned by next_max() in QUICK_GROUP_MIN_MAX_SELECT::get_next() were either causing crashes in Debug builds due to an assertion or being swallowed in Release builds. The changes ensure proper error propagation and add test coverage. The review feedback correctly identifies that the updated assertion is still too restrictive and could cause crashes for other transient errors like deadlocks or query interruptions, suggesting a more robust assertion condition.
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.
DaveGosselin-MariaDB
force-pushed
the
10.11-mdev-25964-lock-bypass
branch
from
5c67c77 to
146032b
Compare
When an uncommitted transaction inserts rows into a table and another statement locks rows in the same table (SELECT ... FOR UPDATE) while computing a MIN or MAX, then: 1. In a Debug build, the server aborts on an assertion 2. In a Release build, the server returns wrong results These errors occur because, while reading a group of rows for computing a MAX, the transaction timeout error was swallowed. Under the scenario described above and captured in the new test at this commit, QUICK_GROUP_MIN_MAX_SELECT::next_max() emits a lock timeout error during QUICK_GROUP_MIN_MAX_SELECT::get_next() but the error was suppressed if we computed a MIN. Keep the MAX result when the MIN call succeeded but the MAX result failed, so the error propagates to the client. Now that we expect an error to propagate on error computing a MAX, drop the assertion.
DaveGosselin-MariaDB
force-pushed
the
10.11-mdev-25964-lock-bypass
branch
from
146032b to
b284321
Compare
1 participant
When an uncommitted transaction inserts rows into a table and another statement locks rows in the same table (SELECT ... FOR UPDATE) while computing a MIN or MAX, then:
Under the scenario described above and captured in the new test at this commit, QUICK_GROUP_MIN_MAX_SELECT::next_max() emits a lock timeout error during QUICK_GROUP_MIN_MAX_SELECT::get_next() but the error was suppressed if we computed a MIN.
Keep the MAX result when the MIN call succeeded but the MAX result failed, so the error propagates to the client.