mirror of
https://github.com/MariaDB/server.git
synced 2025-01-20 22:12:30 +01:00
c784ee2782
There were two problems here:
1. misleading error message
2. abusing KILL QUERY in the test case
1. The server reported "'DELETE FROM t1' failed: 1689: Wait on a lock was
aborted due to a pending exclusive lock", while the proper error message
should be "'DELETE FROM t1' failed: 1317: Query execution was interrupted".
The problem is that the server has two different flags for
signalling that a query is being killed: THD::killed and
mysys_var::abort. The test case triggers a race: sometimes
mysys_var::abort is set earlier than THD::killed. That leads
to the following situation:
- thr_lock() checks mysys_var::abort and returns error status,
since mysys_var::abort is set;
- the caller (mysql_lock_tables()) gets an error from thr_lock(),
but THD::killed is not set, so it decides that thr_lock() couldn't
get a lock due to a pending exclusive lock.
This is a known issue with the server and it's not going to be fixed soon.
5.5 differs from 5.1 here as follows: when thr_lock() returns an error:
- 5.1 continues trying thr_lock() until success;
- 5.5 propagates the error
2. The test case uses KILL QUERY is a highly concurent environment.
The fix is to wait for the dying statement to rest in peace before
executing another DELETE FROM t1.
|
||
|---|---|---|
| .. | ||
| default.daily | ||
| default.experimental | ||
| default.push | ||
| default.weekly | ||
| mysql-next-mr.push | ||
| mysql-trunk.push | ||
| README | ||
| README.experimental | ||
| test-bt | ||
| test-bt-debug | ||
| test-bt-debug-fast | ||
| test-bt-fast | ||
This directory contains collections of test runs that we run during our integration and release testing. Each file contains zero or more lines, with one invocation of mysql-test-run.pl on each. These invocations are written so that, with the assumption that perl is in your search path, any collection can run as a shell script or a batch file, with the parent mysql-test directory being the current working directory. During integration testing, we choose the collection to run by following these steps: 1) We choose the extension to look for, based on these rules: - If we're running a per-push test, we choose ".push" as the extension. - If we're running a daily test, we choose ".daily" as the extension. - If we're running a weekly test, we choose ".weekly" as the extension. 2) If there is a collection that has the same name as the branch we're testing plus the extension as determined in step 1, we choose that collection. 3) If the branch is unknown or we have removed all characters from it and still not found a matching collection, we choose the name "default" plus the extension determined in step 1. If there is no such file, we give up and don't test anything at all. 4) If we haven't found a collection yet, we remove the last character from the branch name and go back to step 2. 5) The commands from the collection are run line by line via execv() or similar system calls. They are not run as a shell script. Shell expansions are not guaranteed to work and most likely won't.