mirror of
https://github.com/MariaDB/server.git
synced 2025-01-16 12:02:42 +01:00
Bug#14248833: 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. sql/sql_update.cc: Bug#14248833: UPDATE ON INNODB TABLE ENTERS RECURSION The check for used key being updated is extended to cover the case when index merge is used.
This commit is contained in:
parent
970da4bdf2
commit
247262347e
1 changed files with 9 additions and 0 deletions
|
@ -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 ||
|
||||
|
|
Loading…
Reference in a new issue