mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-31 11:01:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

row0sel.c:

Browse source 
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.
This commit is contained in:
heikki@hundin.mysql.fi 2005-02-22 21:05:17 +02:00
parent c583eb6954
commit 5f427ec35d
1 changed files with 7 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
innobase/row/row0sel.c
View file

@ -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);