----- Original Message -----
From: "Michael Widenius" <monty@stripped>
To: "Jocelyn Fournier" <joc@stripped>
Cc: <sroussey@stripped>; "Mysql" <internals@stripped>
Sent: Friday, September 27, 2002 10:36 AM
Subject: Re: Problem with insert delayed thread. Perhaps a linuxthread
> >>>>> "Jocelyn" == Jocelyn Fournier <joc@stripped>
> Jocelyn> It seems something else in the code "reset" the value of
> Jocelyn> delayed_insert_threads to 0, which could explain the jump from 42
to 0, but
> Jocelyn> I not yet found what :(
> Just a note about this thread. I am just now making a merge of 4.0
> and the 4.1 trees so that we can make the 4.1 tree publicly available.
> As soon as this is done I will write extend some test cases regarding
> delayed to try to find this problem.
> Jocelyn> Anyway, I'm happy to hear I'm not the only one experiencing
> Jocelyn> delayed_threads under high QPS :)
> Have you taken a look at the tests/test_delayed_insert.pl test we use
> to test insert delayed ?
Yes, I already tried to modify it without any success.
Do you know when FLUSH STATUS is executed by MySQL ? (I never used this
command, so it seems it's triggered internally by something. As the waiting
for table problem seemed to be linked with the FLUSH STATUS problem, I'd
like to check this more thoroughly).
> If you could someway modify this to also look up, it would be much
> easier for us to debug this and find what is going on...
> My guess is that somehow the insert thread handler gets stuck in some
> of the functions handle_inserts() calls waiting for a mutex or table
> lock to get freed.
> (Maybe thr_upgrade_write_delay_lock() ?)
As I have a little more time now (holidays :)), I'll take a look at it.
> If you can find out which function, it would help us a lot in tracking
I wish I could find it :)