diff options
author | Thirunarayanan Balathandayuthapani <thiru@mariadb.com> | 2019-07-24 16:34:14 +0530 |
---|---|---|
committer | Thirunarayanan Balathandayuthapani <thiru@mariadb.com> | 2019-07-24 16:45:05 +0530 |
commit | 8fb39b2c35e991f22911a88cb66ac4aef12eb5a5 (patch) | |
tree | 41f2c0e4822c829ff11bf14cbce634ed0af7bd0e /storage/innobase/ut | |
parent | c22305f0501a26cfe1b87b20e44d336514c69716 (diff) | |
download | mariadb-git-8fb39b2c35e991f22911a88cb66ac4aef12eb5a5.tar.gz |
MDEV-19870 gcol.innodb_virtual_debug_purge doesn't fail if row_vers_old_has_index_entry gives wrong result
1) Whenever purge thread tries to remove the secondary virtual index
entry, purge thread acquires metadata lock for the table and release
dict_operation_lock. After that, it retries the secondary index
deletion if MDL acquired successfully.
2) Inside row_vers_old_has_index_entry(), Change the safe_to_purge
to unsafe_to_purge goto statement. So it can be more appropriate to
return true if it is unsafe_to_purge.
3) Previously, row_vers_old_has_index_entry() returns false if InnoDB
fetched the MDL on the table for the first time. This check(two cases)
should checked only during purge thread. In row_purge_poss_sec(), again
InnoDB checks whether the MDL fetched for the first time. If it is then
InnoDB retry the secondary index deletion logic. So in that case,
InnoDB have to clean up the memory used inside row_vers_old_has_index_entry()
and shouldn't care about return value.
Diffstat (limited to 'storage/innobase/ut')
0 files changed, 0 insertions, 0 deletions