diff options
author | Tatiana A. Nurnberg <azundris@mysql.com> | 2009-10-19 21:42:10 -0700 |
---|---|---|
committer | Tatiana A. Nurnberg <azundris@mysql.com> | 2009-10-19 21:42:10 -0700 |
commit | 5ef63a4f1c2f1abb81caaec639b962837821000f (patch) | |
tree | fa3b244415e186d4804e5701f665beb801ee718b /mysql-test/t/flush_read_lock_kill.test | |
parent | ce0a06935b0bfde25a8fdbad1d6474559b6b7260 (diff) | |
download | mariadb-git-5ef63a4f1c2f1abb81caaec639b962837821000f.tar.gz |
Bug#28141: Control C on query waiting on lock causes ERROR 1053 (server shutdown)
If a thread is killed in the server, we throw "shutdown" only if one is actually in
progress; otherwise, we throw "query interrupted".
Control-C in the mysql command-line client is "incremental" now.
First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
Next Control-C sends KILL CONNECTION
Next Control-C aborts client.
As the first two steps only pertain to an existing query,
Control-C will abort the client right away if no query is running.
client will give more detailed/consistent feedback on Control-C now.
client/mysql.cc:
Extends Control-C handling; enhances up feedback to user.
On 5.0+ servers, we try to be nice and send KILL QUERY first
if Control-C is pressed in the command-line client, but if
that doesn't work, we now give the user the opportunity to
send KILL CONNECTION with another Control-C (and to kill the
client with another Control-C if that somehow doesn't work
either).
mysql-test/t/flush_read_lock_kill.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/kill.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/rpl000001.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
mysql-test/t/rpl_error_ignored_table.test:
we're getting correct "thread killed" rather than
"in shutdown" error now
sql/records.cc:
make error messages on KILL uniform for rr_*()
by folding that handling into rr_handle_error()
sql/sql_class.h:
Only throw "shutdown" when we have one flagged as being in progress;
otherwise, throw "query interrupted" as it's likely to be "KILL CONNECTION"
or related.
Diffstat (limited to 'mysql-test/t/flush_read_lock_kill.test')
-rw-r--r-- | mysql-test/t/flush_read_lock_kill.test | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/mysql-test/t/flush_read_lock_kill.test b/mysql-test/t/flush_read_lock_kill.test index b767a0758d4..6c842f8aff3 100644 --- a/mysql-test/t/flush_read_lock_kill.test +++ b/mysql-test/t/flush_read_lock_kill.test @@ -50,7 +50,7 @@ connection con1; # debug build running without our --debug=make_global..., will be # error 0 (no error). The only important thing to test is that on # debug builds with our --debug=make_global... we don't hang forever. ---error 0,1053,2013 +--error 0,1317,2013 reap; connection con2; |