>>>>> "elble" == elble <elble@stripped> writes:
elble> only a problem when running with --debug turned on, and using
elble> 'insert delayed'...
elble> _my_thread_var() was returning null, and
elble> DBUG_ENTER() dosen't like that.
elble> here's a patch against 3.23.4-alpha:
elble> *** sql/sql_insert.cc Tue Sep 7 19:00:45 1999
elble> --- sql/sql_insert.cc Mon Oct 4 14:56:02 1999
elble> *** 760,766 ****
elble> delayed_insert *di=(delayed_insert*) arg;
elble> THD *thd= &di->thd;
elble> - DBUG_ENTER("handle_delayed_insert");
elble> /* Add thread to THD list so that's it's visible in 'show processlist' */
elble> --- 760,765 ----
elble> *** 779,784 ****
elble> --- 778,784 ----
elble> + DBUG_ENTER("handle_delayed_insert");
elble> if (init_thr_lock() ||
elble> my_pthread_setspecific_ptr(THR_THD, thd) ||
elble> my_pthread_setspecific_ptr(THR_NET, &thd->net))
elble> i'm trying to track down a lockup when using 'insert delayed' a lot.
elble> i have a chunk of code that inserts rows constantly to a table.
elble> every ten minutes, it forks off a child to do selects from that
elble> table. the parent returns to continue to insert rows, but into
elble> a new table. when the child is done processing, it drops the
elble> 'old' table.
elble> but the drop never completes, the server locks up pretty tightly.
elble> you can establish a connection, but only if you're on 'localhost'.
elble> you can run one command (e.g. show processlist), but then you can't
elble> run any more unless you reconnect. when you reconnect, the old
elble> 'show processlist' is in state 'cleaning up' or somesuch...
elble> ring any bells?
DROP TABLE is rather special as it has to ensure that there isn't any
insert delayed threads running on the table, so this could be a source
Could you try to modify the test program 'fork_test.pl' to reproduce