From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 Description of problem: Both version 3.23.36 and 3.23.49a (and probably other versions) of RedHat supplied MySQL packages cause frequent corruption of data tables as shown in: mysql> check table bulkmessage; +---------------------+-------+----------+---------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------------------+-------+----------+---------------------------------------------+ | bulkmessage | check | warning | Table is marked as crashed | | bulkmessage | check | error | Wrong bytesec: 0-0-0 at linkstart: 41273800 | | bulklog.bulkmessage | check | error | Corrupt | +---------------------+-------+----------+---------------------------------------------+ 3 rows in set (11.63 sec) Version-Release number of selected component (if applicable): mysql-3.23.49-3 How reproducible: Always Steps to Reproduce: The problem has not been reduced to a very small isolated script yet. In the actual system, one Java process connects to the database for batch updates to the 'bulkmessage' table using MMMysql 2.0.6 JDBC once per hour. Another process has a single JDBC connection doing continuous updates (about 2 per second) to the same table. This results in a corrupted table within a day. Actual Results: 'check table' detects the corruption shown in the 'description' section above. Expected Results: The table should not get corrupted, of course. Additional info: The www.mysql.com website contains a big warning stating that compiling mysql with gcc 2.96 may lead to table corruption, which in all observed cases went away after switching to a 2.95 compiled mysql version. In our case switching to MySQL AB supplied binaries of MySQL 3.23.49a resolved the problem indeed. It may be wise to follow MySQL AB's advice and compile the Red Hat MySQL packages with gcc 2.95 as well.
Gcc 2.95.x is known buggy, and without a testcase, this bug can't be confirmed or fixed.
Yes, of course you need a test case. I'll try to create one a.s.a.p. In the mean while I'll attach other info that may be relevant (and me be interesting to other experiencing similiar problems). It turns out I was a bit to soon in stating that the MySQL AB supplied binaries don't show the problem: it just appears to take a bit longer before corruption occurs. Since this mysqld binary has been statically linked this leaves only the mysql daemon, the kernel or the hardware as possible culprits. The system is a dual Pentium III 600 system with 1GB RAM, running kernel 2.2.19-7.0.12.
Can you try getting the SRPM for RHL 7.3, disable the assembler in the spec file (look at the %configure statement) and try that? The assembly has had problems in the past....
Thanks for the suggestion. I've not been able to create a testcase yet, however, because we have only 1 SMP machine running RH 7.x. Since it's a production machine I don't have the liberty to experiment with it. In the meanwhile I've run an 'optimize table' on all tables and turned on binary logging. Also a cleaning job halved the row counts of most tables.After that we've not experienced corruption anymore, it has been OK for 6 days now, where usually corruption occurred within 1 or 2 days of the last 'repair table'. Because of all these simultaneous changes, little can be said yet about where the problem lies.
OK, seems to work now. Closing.