Hi!
>>>>> "struanb" == struanb <struanb@stripped> writes:
>> Description:
struanb> Our high-load database application involves large numbers of "insert delayed"
> statements to four separate tables (out of fifteen tables used by our application).
> Several times a week, we notice that MySQL is processing slowly. After running isamchk on
> each table, we discover corruption in only those tables to which we write using "insert
> delayed".
>> From the mysql.err file, it appears that the corruption of the tables are
> preceded (if not caused) by a MySQL crash.
struanb> During various tests, we have managed to observe MySQL crashing following
> execution of "insert delayed" statements on a similar system.
struanb> In the mysql.err file we sometimes (but not always) get lines such as:
struanb> "Delayed insert thread couldn't get requested lock for table XYZ"
struanb> (in fact we get hundreds of thousands of these when we get them at all!)
>> How-To-Repeat:
struanb> Don't know for sure. Try lots of "insert delayed" statements mixed with other
> statements on tables with hundreds of thousands of rows.
>> Fix:
struanb> Shutdown MySQL and then run isamchk -r on affected tables.
struanb> Alternatively, avoiding use of "insert delayed" may prevent this problem.
The glibc Linux library has a fatal bug in pthread_cond_timedwait()
that is used in MySQL when you use INSERT DELAYED. MySQL 3.23.7 has and
MySQL 3.22.8 will have a workaround for this.
Regards
Monty
PS: Starting next year we will create a new mailing list:
bugs@stripped ; To this list we will only accept bug reports,
posted with mysqlbug and with a repeatable example. All MySQL
developers will subscribe and read this list! This will ensure that
all posted bugs will get solved quickly!
