only a problem when running with --debug turned on, and using
'insert delayed'...
_my_thread_var() was returning null, and
DBUG_ENTER() dosen't like that.
here's a patch against 3.23.4-alpha:
*** sql/sql_insert.cc Tue Sep 7 19:00:45 1999
--- sql/sql_insert.cc Mon Oct 4 14:56:02 1999
***************
*** 760,766 ****
{
delayed_insert *di=(delayed_insert*) arg;
THD *thd= &di->thd;
- DBUG_ENTER("handle_delayed_insert");
pthread_detach_this_thread();
/* Add thread to THD list so that's it's visible in 'show processlist' */
--- 760,765 ----
***************
*** 779,784 ****
--- 778,784 ----
}
#endif
+ DBUG_ENTER("handle_delayed_insert");
if (init_thr_lock() ||
my_pthread_setspecific_ptr(THR_THD, thd) ||
my_pthread_setspecific_ptr(THR_NET, &thd->net))
i'm trying to track down a lockup when using 'insert delayed' a lot.
i have a chunk of code that inserts rows constantly to a table.
every ten minutes, it forks off a child to do selects from that
table. the parent returns to continue to insert rows, but into
a new table. when the child is done processing, it drops the
'old' table.
but the drop never completes, the server locks up pretty tightly.
you can establish a connection, but only if you're on 'localhost'.
you can run one command (e.g. show processlist), but then you can't
run any more unless you reconnect. when you reconnect, the old
'show processlist' is in state 'cleaning up' or somesuch...
ring any bells?
--
Andrew W. Elble | The telephone was ringing, That's when
elble@stripped | I handed it to Liz. She said, "This isn't
TeleCommunications Engineering | who it would be, If it wasn't who it is"
Northwestern University | --Phish
