Commit 74126079 authored by unknown's avatar unknown

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
parent 3a192cf5
......@@ -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
......
......@@ -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;
......
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;
#
# 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;
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment