Maciek,

I may have found the bug, which was introduced in 4.0.5. If binlogging is not switched on, queries of type

INSERT INTO ... SELECT ...

CREATE TABLE .... SELECT ...

may hang.

Workaround: switch binlogging on. The fix will be in 4.0.6. The bug does not exist in the 3.23 branch.

Regards,

Heikki Innobase Oy

ChangeSet 1.1448 02/12/03 18:16:48 hei...@hundin.mysql.fi +1 -0 row0sel.c: Fix a hang introduced in 4.0.5 in INSERT INTO ... SELECT ... when binlogging is not on

innobase/row/row0sel.c 1.27 02/12/03 18:16:39 hei...@hundin.mysql.fi +10 -2 Fix a hang introduced in 4.0.5 in INSERT INTO ... SELECT ... when binlogging is not on

# This is a BitKeeper patch. What follows are the unified diffs for the # set of deltas contained in the patch. The rest of the patch, the part # that BitKeeper cares about, is below these diffs. # User: heikki # Host: hundin.mysql.fi # Root: /home/heikki/mysql-4.0

--- 1.26/innobase/row/row0sel.c Thu Nov 14 00:38:17 2002 +++ 1.27/innobase/row/row0sel.c Tue Dec 3 18:16:39 2002 @@ -2702,14 +2702,22 @@

unique_search_from_clust_index = TRUE;

- if (prebuilt->select_lock_type == LOCK_NONE + if (trx->mysql_n_tables_locked == 0 + && prebuilt->select_lock_type == LOCK_NONE && trx->isolation_level > TRX_ISO_READ_UNCOMMITTED && trx->read_view) {

/* This is a SELECT query done as a consistent read, and the read view has already been allocated: let us try a search shortcut through the hash - index */ + index. + NOTE that we must also test that + mysql_n_tables_locked == 0, because this might + also be INSERT INTO ... SELECT ... or + CREATE TABLE ... SELECT ... . Our algorithm is + NOT prepared to inserts interleaved with the SELECT, + and if we try that, we can deadlock on the adaptive + hash index semaphore! */

if (btr_search_latch.writer != RW_LOCK_NOT_LOCKED) { /* There is an x-latch request: release