1berry/MariaDB-server
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Bug#65745: UPDATE ON INNODB TABLE ENTERS RECURSION

Browse Source 
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 <evgeny.potemkin@oracle.com>
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.
This commit is contained in:
Joerg Bruehe 2012-06-28 20:03:53 +02:00
parent 33d9d40ccd
commit 62884afab5
2 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
VERSION
View File

@ -1,4 +1,4 @@
MYSQL_VERSION_MAJOR=5
MYSQL_VERSION_MINOR=5
MYSQL_VERSION_PATCH=25
MYSQL_VERSION_PATCH=25a
MYSQL_VERSION_EXTRA=

9
sql/sql_update.cc
View File

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