>>>>> "Steven" == Steven Roussey <sroussey@stripped> writes:
Steven> We also feel this bug, so we changed to normal inserts, but without
Steven> concurrent inserts, MySQL slows to a crawl. MySQL holds all the inserts for
Steven> that table because they are locked, and it fills up the number of threads.
Steven> In Linux at least, we can not change the per thread amount of memory MySQL
Steven> reserves so we must cap the number of threads. Therefore, the web site
Steven> stops. Ick.
I will relase MySQL 3.22.8 VERY soon; This has a workaround for the
INSERT DELAYED problem.
Steven> We want to switch to MySQL 2.23.* but we are afraid. We are having enough
Steven> problems with 2.22.27 that the thought of moving to an alpha version gives
Steven> us serious pause. But there are also enough things in there that we want to
Steven> move right away. What a pickle. So I have some questions:
Steven> When will 2.23.* turn to beta?
As soon as we haven't got any bad bug reports for a month; We are not
anymore adding any features that would make it unstable again. Many
users are actually running this and apart from a couple of small
problems (which are fixed in 3.23.8) it seams works very well!
As 3.23 is backward compatible to 3.22, it's actually very easy to
just put in the new server and start testing this. If things doesn't
work out, you just have to start the old mysqld daemon instead.
(The above assumes of course that you haven't changed any tables to
the new MyISAM format).
Steven> Will 2.22.28 fix the insert delayed problem on Linux?
Yes. The workaround in 3.22.28 is to change 'pthread_cond_timedwait()' in
sql/sql_insert.cc to pthread_cond_wait() until they have managed to
fix the bug in glibc.
Steven> Steven Roussey
Steven> Network54 Corporation