Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6
-
Can result in unexpected behaviour
Description
Please see the repro file for code to reproduce.
The issue is present in about 10% / iteration on localhost (the probablity lowers rapidly with higher latency between the DB and client). To be able to reproduce this issue reliably, the repro code is in php language to be able to loop until the issue is reproduced.
I have verified the repro on multiple servers and I can confirm 100% repeatability.
Command used to start the MariaDB:
sudo docker run -it --network=host -e MYSQL_ROOT_PASSWORD=r -e MYSQL_DATABASE=d -e MYSQL_TCP_PORT=4057 mariadb:10.6
|
Command used to run the repro:
php repro-KillWithoutErrorAffectsTransaction.php
|
I tested these DB engines:
- MariaDB 10.5 and lower: none
- MariaDB 10.6: from 10.6.19
- MariaDB 10.7, 10.8, 10.9, 10.10: none
- MariaDB 10.11: from 10.11.9
- MariaDB 11.0: none
- MariaDB 11.1: from 11.1.6
- MariaDB 11.2: from 11.2.5
- MariaDB 11.3: none
- MariaDB 11.4 and higher: all
- MySQL: none
(TLTR; it seems some bad patch was merged into 10.6.19 and upwards)
The issue and the expectation is, when "KILL QUERY xxx" command is sent to MariaDB it must either be ignored if there is no active query, or terminate the current query and raise 1317 error code.
Currently, the kill command can kill active query without raising the 1317 error code (judging from the side effect/following select query). This implies the client cannot handle/detect the query interruption and can assume correctly wrong locked value therefore.
As this behaviour is highly dangerous I am marking this issue as CRITICAL.
Attachments
Issue Links
- relates to
-
MDEV-34108 Inappropriate semi-consistent read in RC if innodb_snapshot_isolation=ON
-
- Closed
-