MySQL Bugs: #8613: FTS: Try to repair table

Bug #8613	FTS: Try to repair table
Submitted:	18 Feb 2005 23:10	Modified:	19 Feb 2005 17:14
Reporter:	Steven Roussey	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S2 (Serious)
Version:	4.0.23	OS:	Linux (RHEL 3)
Assigned to:		CPU Architecture:	Any

Description:
Inserting a record into a table causes the table to become crashed.

Dual Athlon MP

How to repeat:
There is a table and a query and a trace file uploaded to the ftp secret directory.

To repeat: run the sql query against the table. I have put up a trace file that shows the results. You can fix the table with myisamchk -r or myisamchk -o and the error will repeat again. However, if you use REPAIR TABLE ... USE_FRM the table will then accept the query. So this information may help you fix myisamchk to find and really fix the error inside the file. 

However, this may or may not help you find why MySQL 4.0.20+ (Maybe 4.0.19, but I've never tested it) corrupts tables. I've looked over my previous notes and found table corruption on FTS tables when I upgraded from 4.0.17 to 4.0.20. This time around I went from 4.0.17 to 4.0.23 and have the same problems. My notes say that 4.0.18 was safe, but I decided to not use it on the server setup for searching anyway, and I can't remeber if I was just cautious or if I had encountered something that I didn't put in my notes.

hi

can you please attatch the SHOW CREATE [table] and query statements so that we can reproduce this bug ?

thanks.

sorry for confusion, there's no need to attach anything :)

Run the query on Slackware 10.0 and against server build from BK source
I wasn't able for to get the behavior reported:

miguel@hegel:~/dbs/4.0$ bin/mysql -e"check table forums_posts_1239959" bug8613 -uroot
+------------------------------+-------+----------+----------+
| Table                        | Op    | Msg_type | Msg_text |
+------------------------------+-------+----------+----------+
| bug8613.forums_posts_1239959 | check | status   | OK       |
+------------------------------+-------+----------+----------+
miguel@hegel:~/dbs/4.0$ bin/mysql -uroot bug8613 < /home/miguel/f/testbug8613.sql
miguel@hegel:~/dbs/4.0$ bin/mysql -e"check table forums_posts_1239959" bug8613 -uroot
+------------------------------+-------+----------+----------+
| Table                        | Op    | Msg_type | Msg_text |
+------------------------------+-------+----------+----------+
| bug8613.forums_posts_1239959 | check | status   | OK       |
+------------------------------+-------+----------+----------+
miguel@hegel:~/dbs/4.0$ bin/mysql -e"select version()"  -uroot
+------------------+
| version()        |
+------------------+
| 4.0.24-debug-log |
+------------------+
miguel@hegel:~/dbs/4.0$

I must admit that I was shocked that you'd repeat the test case. So I tested it across servers that have different architectures and versions of Linux. I found the conditions to make it happen, and I found a fix.

:)

I can't repeat the error on Intel machines at all. It is an AMD issue. And on AMD machines, it has a problem only with newer builds (newer meaning, like the last year or so). So I'm guessing that something changed with the build system, but it is only a guess.

What I do know is that it is an interplay between MySQL, AMD, and the NTPL thread library. Starting MySQL with LD_ASSUME_KERNEL=2.4.19 eliminates the problem. I checked this several times to be sure.

The irony is that this is happening on a temporary (and old) Athlon MP server that will soon be replaced with an Intel...