From 62884afab552e96467b3da03d84f0c7c97eb43c9 Mon Sep 17 00:00:00 2001 From: Joerg Bruehe Date: Thu, 28 Jun 2012 20:03:53 +0200 Subject: [PATCH] Bug#65745: UPDATE ON INNODB TABLE ENTERS RECURSION Introduction of cost based decision on filesort vs index for UPDATE statements changed detection of the fact that the index used to scan the table is being updated. The new design missed the case of index merge when there is no single index to check. That was worked until a recent change in InnoDB after which it went into infinite recursion if update of the used index wasn't properly detected. The fix consists of 'used key being updated' detection code from 5.1. Patch done by Evgeny Potemkin and transferred into the 5.5.25a release build by Joerg Bruehe. This changeset is the difference between MySQL 5.5.25 and 5.5.25a. --- VERSION | 2 +- sql/sql_update.cc | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/VERSION b/VERSION index 6111f6d453f..48e6c183915 100644 --- a/VERSION +++ b/VERSION @@ -1,4 +1,4 @@ MYSQL_VERSION_MAJOR=5 MYSQL_VERSION_MINOR=5 -MYSQL_VERSION_PATCH=25 +MYSQL_VERSION_PATCH=25a MYSQL_VERSION_EXTRA= diff --git a/sql/sql_update.cc b/sql/sql_update.cc index 754170e4c55..c4a95edcfc2 100644 --- a/sql/sql_update.cc +++ b/sql/sql_update.cc @@ -450,6 +450,15 @@ int mysql_update(THD *thd, { // Check if we are modifying a key that we are used to search with: used_key_is_modified= is_key_used(table, used_index, table->write_set); } + else if (select && select->quick) + { + /* + select->quick != NULL and used_index == MAX_KEY happens for index + merge and should be handled in a different way. + */ + used_key_is_modified= (!select->quick->unique_key_range() && + select->quick->is_keys_used(table->write_set)); + } #ifdef WITH_PARTITION_STORAGE_ENGINE if (used_key_is_modified || order ||