Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4(EOL), 10.5
-
None
Description
Binary protocol prepared statement execution, which happens after cluster wide conflict, may crash in item parameter setup phase for:
append_query_string (csinfo=0xa5a5a5a5a5a5a5a5, to=0x7fce93673ff0, str=0x7fcea8059458 "", len=11, no_backslash=false)
Where character set info is not valid.
The problem can be reproduced in two node cluster with sysbench:
sysbench --mysql-host=127.0.0.1 --mysql-port=16001 --mysql-user=root --mysql-password= --mysql-db=sbtest --mysql-ignore-errors=all --time=600 --threads=8 --table-size=20 --tables=3 --report-interval=5 /usr/share/sysbench/oltp_write_only.lua run
Attachments
Activity
Two PRs were submitted for this issue.
- https://github.com/MariaDB/server/pull/2026
contains the proposed fix for the issue - https://github.com/MariaDB/server/pull/2027
contains a mtr test for reproducing the issue. The test required a modified version of the mysqltest executable
and these might be rejected in the review. However, although rudimentary, the test itself deterministically makes the issue to surface.
- 10.4 : bb-10.4-
MDEV-27649-galera - 10.5 : bb-10.5-
MDEV-27649-galera
The analysis of this issue revealed that the problem happens if a prepared statement (PS) has been prepared, and the first EXECUTE command will fail due to cluster wide conflict, so early that EXECUTE processing has not yet started. Such situation is possible, e.g. if a PS is executed within a multi statement transaction, and the transaction is holding some offending locks with replicated transactions being applied in the node. And the cluster conflict is detected right after the packet, containing the PS EXECUTE command, has been read from client protocol.
The first EXECUTE command carries type information (e.g. character set definition), and latter EXECUTE commands are optimized to not repeat this type information. The MYSQL_STMT struct in client side appears to maintain MYSQL_STMT::send_type_to_server boolean for this purpose. The server responds with deadlock error when the the first PS EXECUTE fails, but in client side (I assume) send_type_to_server is nevertheless set to true, and following EXECUTE will then not carry type information anymore.
And this is bad, because the first EXECUTE execution did not even start, the type information is not recorded in server side.