Bug #10901

Analyze table corrupts the state on
data_file_length, records, index_file_length...
by writing the shared state when there is an updated internal
state due to inserts or deletes
Fixed by synching the shared state with the internal state before
writing it to disk
Added test cases of 2 error cases and a normal case in new
analyze test case

BitKeeper/etc/logging_ok

@@ -104,6 +104,7 @@ monty@tik.
 monty@tik.mysql.fi
 monty@tramp.mysql.fi
 monty@work.mysql.com
+mronstrom@mysql.com
 mwagner@cash.mwagner.org
 mwagner@evoq.mwagner.org
 mwagner@here.mwagner.org

myisam/mi_check.c

@@ -3623,6 +3623,12 @@ int update_state_info(MI_CHECK *param, MI_INFO *info,uint update)
       if (!share->state.create_time)
 	share->state.create_time=share->state.check_time;
     }
+    /*
+      When tables are locked we haven't synched the share state and the
+      real state for a while so we better do it here before synching
+      the share state to disk.
+    */
+    share->state.state= *info->state;
     if (mi_state_info_write(share->kfile,&share->state,1+2))
       goto err;
     share->changed=0;

mysql-test/r/analyze.result

+create table t1 (a bigint);
+lock tables t1 write;
+insert into t1 values(0);
+analyze table t1;
+Table	Op	Msg_type	Msg_text
+test.t1	analyze	status	OK
+unlock tables;
+check table t1;
+Table	Op	Msg_type	Msg_text
+test.t1	check	status	OK
+drop table t1;
+create table t1 (a bigint);
+insert into t1 values(0);
+lock tables t1 write;
+delete from t1;
+analyze table t1;
+Table	Op	Msg_type	Msg_text
+test.t1	analyze	status	OK
+unlock tables;
+check table t1;
+Table	Op	Msg_type	Msg_text
+test.t1	check	status	OK
+drop table t1;
+create table t1 (a bigint);
+insert into t1 values(0);
+analyze table t1;
+Table	Op	Msg_type	Msg_text
+test.t1	analyze	status	OK
+check table t1;
+Table	Op	Msg_type	Msg_text
+test.t1	check	status	OK
+drop table t1;

mysql-test/t/analyze.test

+#
+# Bug #10901 Analyze Table on new table destroys table
+# This is minimal test case to get error
+# The problem was that analyze table wrote the shared state to the file and this
+# didn't include the inserts while locked. A check was needed to ensure that
+# state information was not updated when executing analyze table for a locked table.
+# The analyze table had to be within locks and check table had to be after unlocking
+# since then it brings the wrong state from disk rather than from the currently
+# correct internal state. The insert is needed since it changes the file state,
+# number of records.
+# The fix is to synchronise the state of the shared state and the current state before
+# calling mi_state_info_write
+#
+create table t1 (a bigint);
+lock tables t1 write;
+insert into t1 values(0);
+analyze table t1;
+unlock tables;
+check table t1;
+
+drop table t1;
+
+create table t1 (a bigint);
+insert into t1 values(0);
+lock tables t1 write;
+delete from t1;
+analyze table t1;
+unlock tables;
+check table t1;
+
+drop table t1;
+
+create table t1 (a bigint);
+insert into t1 values(0);
+analyze table t1;
+check table t1;
+
+drop table t1;
+