Loading BitKeeper/etc/logging_ok +1 −0 Original line number Diff line number Diff line Loading @@ -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 Loading myisam/mi_check.c +8 −0 Original line number Diff line number Diff line Loading @@ -3623,6 +3623,14 @@ 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. Only when table is write locked is it necessary to perform this synch. */ if (info->lock_type == F_WRLCK) share->state.state= *info->state; if (mi_state_info_write(share->kfile,&share->state,1+2)) goto err; share->changed=0; Loading mysql-test/r/analyze.result 0 → 100644 +32 −0 Original line number Diff line number Diff line 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 0 → 100644 +39 −0 Original line number Diff line number Diff line # # 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; Loading
BitKeeper/etc/logging_ok +1 −0 Original line number Diff line number Diff line Loading @@ -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 Loading
myisam/mi_check.c +8 −0 Original line number Diff line number Diff line Loading @@ -3623,6 +3623,14 @@ 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. Only when table is write locked is it necessary to perform this synch. */ if (info->lock_type == F_WRLCK) share->state.state= *info->state; if (mi_state_info_write(share->kfile,&share->state,1+2)) goto err; share->changed=0; Loading
mysql-test/r/analyze.result 0 → 100644 +32 −0 Original line number Diff line number Diff line 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 0 → 100644 +39 −0 Original line number Diff line number Diff line # # 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;