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:
  Logging to logging@openlogging.org accepted

4 files changed, 78 insertions, 0 deletions

diff --git a/BitKeeper/etc/logging_ok b/BitKeeper/etc/logging_ok
index 499e3cdd4f5..f20e8ebc953 100644
--- a/BitKeeper/etc/logging_ok
+++ b/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
diff --git a/myisam/mi_check.c b/myisam/mi_check.c
index e78d831fde7..16946adb3e8 100644
--- a/myisam/mi_check.c
+++ b/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;
diff --git a/mysql-test/r/analyze.result b/mysql-test/r/analyze.result
new file mode 100644
index 00000000000..0b44a502b13
--- /dev/null
+++ b/mysql-test/r/analyze.result
@@ -0,0 +1,32 @@
+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;
diff --git a/mysql-test/t/analyze.test b/mysql-test/t/analyze.test
new file mode 100644
index 00000000000..faf30279c68
--- /dev/null
+++ b/mysql-test/t/analyze.test
@@ -0,0 +1,39 @@
+#
+# 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;
+