2
# Bug #10901 Analyze Table on new table destroys table
3
# This is minimal test case to get error
4
# The problem was that analyze table wrote the shared state to the
5
# file and this didn't include the inserts while locked. A check was
6
# needed to ensure that state information was not updated when
7
# executing analyze table for a locked table. The analyze table had
8
# to be within locks and check table had to be after unlocking since
9
# then it brings the wrong state from disk rather than from the
10
# currently correct internal state. The insert is needed since it
11
# changes the file state, number of records. The fix is to
12
# synchronise the state of the shared state and the current state
13
# before calling mi_state_info_write
16
create table t1 (a bigint);
18
insert into t1 values(0);
25
create table t1 (a bigint);
26
insert into t1 values(0);
35
create table t1 (a bigint);
36
insert into t1 values(0);
42
# Bug #14902 ANALYZE TABLE fails to recognize up-to-date tables
43
# minimal test case to get an error.
44
# The problem is happening when analysing table with FT index that
45
# contains stopwords only. The first execution of analyze table should
46
# mark index statistics as up to date so that next execution of this
47
# statement will end up with Table is up to date status.
48
create table t1 (a mediumtext, fulltext key key1(a)) charset utf8 collate utf8_general_ci engine myisam;
49
insert into t1 values ('hello');
57
# bug#15225 (ANALYZE temporary has no effect)
59
create temporary table t1(a int, index(a));
60
insert into t1 values('1'),('2'),('3'),('4'),('5');
65
--echo End of 4.1 tests
68
# Bug #30495: optimize table t1,t2,t3 extended errors
70
create table t1(a int);
72
analyze table t1 extended;
74
optimize table t1 extended;
77
--echo End of 5.0 tests