Description:
when installed in a chroot environment and running "./mysql-test-run"
1 out of the 268 tests fails with the statement:
fulltext [ fail ]
Errors are (from /home/hib/src/mysql-standard-4.1.8-pc-linux-i686-icc-glibc23/mysql-test/var/log/mysqltest-time) :
/home/hib/src/mysql-standard-4.1.8-pc-linux-i686-icc-glibc23/bin/mysqltest: At line 324: Result length mismatch
(the last lines may be the most important ones)
Below are the diffs between actual and expected results:
-------------------------------------------------------
*** r/fulltext.result Tue Dec 14 17:43:29 2004
--- r/fulltext.reject Thu Feb 10 16:51:35 2005
***************
*** 394,399 ****
--- 394,401 ----
INSERT INTO t1 VALUES ('Jesses Hasse Ling and his syncopators of Swing');
REPAIR TABLE t1;
Table Op Msg_type Msg_text
+ test.t1 repair error 22 when fixing table
+ test.t1 repair warning Number of rows changed from 0 to 1
test.t1 repair status OK
select count(*) from t1;
count(*)
-------------------------------------------------------
The SQL statements thrown at the db server are (from the log):
29 Query CREATE TABLE t1 (h text, FULLTEXT (h));
29 Query INSERT INTO t1 VALUES ('Jesses Hasse Ling and his syncopators of Swing')
29 Query REPAIR TABLE t1
29 Query select count(*) from t1
29 Query drop table t1
when reproduced in a mysql shell:
mysql> CREATE TABLE t1 (h text, FULLTEXT (h));
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO t1 VALUES ('Jesses Hasse Ling and his syncopators of Swing') ;
Query OK, 1 row affected (0.00 sec)
mysql> select * from t1;
+------------------------------------------------+
| h |
+------------------------------------------------+
| Jesses Hasse Ling and his syncopators of Swing |
+------------------------------------------------+
1 row in set (0.00 sec)
mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 1 |
+----------+
1 row in set (0.00 sec)
mysql> repair table t1;
050210 15:17:59 [Note] Retrying repair of: './test/t1' with keycache
+---------+--------+----------+------------------------------------+
| Table | Op | Msg_type | Msg_text |
+---------+--------+----------+------------------------------------+
| test.t1 | repair | error | 22 when fixing table |
| test.t1 | repair | warning | Number of rows changed from 0 to 1 |
| test.t1 | repair | status | OK |
+---------+--------+----------+------------------------------------+
3 rows in set (0.00 sec)
mysql> select * from t1;
+------------------------------------------------+
| h |
+------------------------------------------------+
| Jesses Hasse Ling and his syncopators of Swing |
+------------------------------------------------+
1 row in set (0.00 sec)
mysql> select count(*) from t1 ;
+----------+
| count(*) |
+----------+
| 1 |
+----------+
1 row in set (0.00 sec)
it seems like the opperation of the DB is correct and the test script cannot handle the output.
can annyone verrify that this is the case.
regards hilmar
How to repeat:
Installed a secondary copy on our test server.
This resulted in the same behavoir.
note: all installations are chrooted.
Suggested fix:
add the output to the mysql-test script.
Description: when installed in a chroot environment and running "./mysql-test-run" 1 out of the 268 tests fails with the statement: fulltext [ fail ] Errors are (from /home/hib/src/mysql-standard-4.1.8-pc-linux-i686-icc-glibc23/mysql-test/var/log/mysqltest-time) : /home/hib/src/mysql-standard-4.1.8-pc-linux-i686-icc-glibc23/bin/mysqltest: At line 324: Result length mismatch (the last lines may be the most important ones) Below are the diffs between actual and expected results: ------------------------------------------------------- *** r/fulltext.result Tue Dec 14 17:43:29 2004 --- r/fulltext.reject Thu Feb 10 16:51:35 2005 *************** *** 394,399 **** --- 394,401 ---- INSERT INTO t1 VALUES ('Jesses Hasse Ling and his syncopators of Swing'); REPAIR TABLE t1; Table Op Msg_type Msg_text + test.t1 repair error 22 when fixing table + test.t1 repair warning Number of rows changed from 0 to 1 test.t1 repair status OK select count(*) from t1; count(*) ------------------------------------------------------- The SQL statements thrown at the db server are (from the log): 29 Query CREATE TABLE t1 (h text, FULLTEXT (h)); 29 Query INSERT INTO t1 VALUES ('Jesses Hasse Ling and his syncopators of Swing') 29 Query REPAIR TABLE t1 29 Query select count(*) from t1 29 Query drop table t1 when reproduced in a mysql shell: mysql> CREATE TABLE t1 (h text, FULLTEXT (h)); Query OK, 0 rows affected (0.00 sec) mysql> INSERT INTO t1 VALUES ('Jesses Hasse Ling and his syncopators of Swing') ; Query OK, 1 row affected (0.00 sec) mysql> select * from t1; +------------------------------------------------+ | h | +------------------------------------------------+ | Jesses Hasse Ling and his syncopators of Swing | +------------------------------------------------+ 1 row in set (0.00 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 1 | +----------+ 1 row in set (0.00 sec) mysql> repair table t1; 050210 15:17:59 [Note] Retrying repair of: './test/t1' with keycache +---------+--------+----------+------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------+--------+----------+------------------------------------+ | test.t1 | repair | error | 22 when fixing table | | test.t1 | repair | warning | Number of rows changed from 0 to 1 | | test.t1 | repair | status | OK | +---------+--------+----------+------------------------------------+ 3 rows in set (0.00 sec) mysql> select * from t1; +------------------------------------------------+ | h | +------------------------------------------------+ | Jesses Hasse Ling and his syncopators of Swing | +------------------------------------------------+ 1 row in set (0.00 sec) mysql> select count(*) from t1 ; +----------+ | count(*) | +----------+ | 1 | +----------+ 1 row in set (0.00 sec) it seems like the opperation of the DB is correct and the test script cannot handle the output. can annyone verrify that this is the case. regards hilmar How to repeat: Installed a secondary copy on our test server. This resulted in the same behavoir. note: all installations are chrooted. Suggested fix: add the output to the mysql-test script.