From 5f427ec35debeb78b4404023a23e6ae07914fc15 Mon Sep 17 00:00:00 2001
From: "heikki@hundin.mysql.fi" <>
Date: Tue, 22 Feb 2005 21:05:17 +0200
Subject: [PATCH] row0sel.c: Fix bug #8677: if one used LOCK TABLES, created
an InnoDB temp table, and did a multi-table update where a MyISAM table was
the update table and the temp table was a read table, then InnoDB aserted in
row0sel.c because n_mysql_tables_in_use was 0. Also, we remove the assertion
altogether and just print an error to the .err log if this important
consistency check fails. Then it is up to the user to read the .err log and
notice the problem if there still are errors in MySQL's table locking.
---
innobase/row/row0sel.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/innobase/row/row0sel.c b/innobase/row/row0sel.c
index 52228caccb0..2de02081176 100644
--- a/innobase/row/row0sel.c
+++ b/innobase/row/row0sel.c
@@ -2912,14 +2912,19 @@ row_search_for_mysql(
ut_error;
}
- if (trx->n_mysql_tables_in_use == 0) {
+ if (trx->n_mysql_tables_in_use == 0
+ && prebuilt->select_lock_type == LOCK_NONE) {
+ /* Note that if MySQL uses an InnoDB temp table that it
+ created inside LOCK TABLES, then n_mysql_tables_in_use can
+ be zero; in that case select_lock_type is set to LOCK_X in
+ ::start_stmt. */
+
fputs(
"InnoDB: Error: MySQL is trying to perform a SELECT\n"
"InnoDB: but it has not locked any tables in ::external_lock()!\n",
stderr);
trx_print(stderr, trx);
fputc('\n', stderr);
- ut_a(0);
}
/* fprintf(stderr, "Match mode %lu\n search tuple ", (ulong) match_mode);