Fix for bug#20670 "UPDATE using key and invoking trigger that modifies
this key does not stop" (5.1 version). UPDATE statement which WHERE clause used key and which invoked trigger that modified field in this key worked indefinetely. This problem occured because in cases when UPDATE statement was executed in update-on-the-fly mode (in which row is updated right during evaluation of select for WHERE clause) the new version of the row became visible to select representing WHERE clause and was updated again and again. We already solve this problem for UPDATE statements which does not invoke triggers by detecting the fact that we are going to update field in key used for scanning and performing update in two steps, during the first step we gather information about the rows to be updated and then doing actual updates. We also do this for MULTI-UPDATE and in its case we even detect situation when such fields are updated in triggers (actually we simply assume that we always update fields used in key if we have before update trigger). The fix simply extends this check which is done with help of check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() routine/method in such way that it also detects cases when field used in key is updated in trigger. We do this by changing check_if_key_used() to take field bitmap instead field list as argument and passing TABLE::write_set to it (we also have to add info about fields used in triggers to this bitmap a bit earlier). As nice side-effect we have more precise and thus more optimal perfomance-wise check for the MULTI-UPDATE. Also check_if_key_used() routine and similar method were renamed to is_key_used()/is_keys_used() in order to better reflect that it is simple boolean predicate. Finally, partition_key_modified() routine now also takes field bitmap instead of field list as argument.
Showing
Please register or sign in to comment