Hello Davi!
* Davi Arnaut <Davi.Arnaut@stripped> [08/10/01 18:24]:
> # At a local mysql-5.1 repository of davi
>
> 2754 Davi Arnaut 2008-10-01
> Bug#37481: status.test fails randomly
>
> Disable concurrent inserts as it might cause the lock wait
> values to fluctuate during tests and ensure that tables are
> unlocked after a insert by sending a dummy select query. This
> will ensure that a posterior request for a read lock on the
> table won't wait (Table_locks_waited).
As we have discussed on IRC the source of the problem are not concurrent
inserts but rather the fact that we try to obtain lock on a table in one
connection without ensuring that insert which was executed in another
connection has released the lock. Addition of dummy select query after
insert ensures that tables are unlocked and is enough to prevent test
failures described in the bug report. Concurrent inserts are disabled
just for extra safety.
I think it is important to reflect these facts precisely in ChangeSet
and per-file comments. Please update them accordingly.
>
> Remove comments that calculated the Table_locks_immediate. This
> value is not tested anymore and it's calculation did not
> reflect the actual value.
> modified:
> mysql-test/r/status.result
> mysql-test/t/status.test
>
> per-file messages:
> mysql-test/r/status.result
> Update test case result.
> mysql-test/t/status.test
> Disable concurrent inserts and ensure that tables are unlocked
> after a insert.
...
> === modified file 'mysql-test/t/status.test'
> --- a/mysql-test/t/status.test 2008-09-05 10:44:16 +0000
> +++ b/mysql-test/t/status.test 2008-10-01 14:17:54 +0000
> @@ -4,6 +4,11 @@
> # embedded server causes different stat
> -- source include/not_embedded.inc
>
> +# Disable concurrent inserts to avoid sporadic test failures as it might
> +# affect the the value of variables used throughout the test case.
> +set @old_concurrent_insert= @@global.concurrent_insert;
> +set @@global.concurrent_insert= 0;
> +
> # PS causes different statistics
> --disable_ps_protocol
>
> @@ -12,54 +17,43 @@ connect (con2,localhost,root,,);
>
> flush status;
>
> -# Logging to the general query log table (--log-output=table --log) increments
> -# Table_locks_immediate with each query, so here Immediate becomes 1
> show status like 'Table_lock%';
> -# ++Immediate = 2
> select * from information_schema.session_status where variable_name like
> 'Table_lock%';
>
> connection con1;
> -# ++Immediate = 3
> -SET SQL_LOG_BIN=0;
> -set @old_general_log = @@global.general_log;
> +--echo # con1
May be it makes sense to be a bit more verbose in such situations? E.g:
--echo # Switching to connection 'con1'
> +set sql_log_bin=0;
> +set @old_general_log = @@global.general_log;
> set global general_log = 'OFF';
> --disable_warnings
> -# ++Immediate = 4
> drop table if exists t1;
> --enable_warnings
>
> -# ++Immediate = 5
> create table t1(n int) engine=myisam;
> -# Immediate + 2 = 7
> insert into t1 values(1);
> +select 1;
Please add short comment describing why do you need this dummy select.
Something like:
# Execute dummy select in order to ensure that close_thread_tables() was
# called for previous statement and thus table t1 was unlocked.
Will do the trick...
I think it is OK to push this patch after addressing the above comments!
--
Dmitry Lenev, Software Developer
MySQL AB, www.mysql.com
Are you MySQL certified? http://www.mysql.com/certification
