mirror of
https://github.com/MariaDB/server.git
synced 2025-01-15 19:42:28 +01:00
e5c4c0842d
opt_calc_index_goodness(): Correct an inaccurate condition. We can very well use a clustered index of a table that is subject to online rebuild. But we must not choose an index that has not been committed (it is a secondary index that was not fully created) or that is corrupted or not a normal B-tree index. opt_search_plan_for_table(): Remove some redundant code, now that opt_calc_index_goodness() checks against corrupted indexes. The test case allows this code to be exercised. The main observation in the following: ./mtr --rr innodb.stats_persistent rr replay var/log/mysqld.1.rr/latest-trace should be that when opt_search_plan_for_table() is being invoked by dict_stats_update_persistent() on the being-altered statistics table in the 2nd call after ha_innobase::inplace_alter_table(), and the fix in opt_calc_index_goodness() is absent, it would choose the code path if (n_fields == 0), that is, a full table scan, instead of searching for the record. The GDB commands to execute in "rr replay" would be as follows: break ha_innobase::inplace_alter_table continue break opt_search_plan_for_table continue continue next next … Reviewed by: Vladislav Lesin |
||
---|---|---|
.. | ||
archive | ||
binlog | ||
binlog_encryption | ||
client | ||
compat | ||
csv | ||
encryption | ||
engines | ||
federated | ||
funcs_1 | ||
funcs_2 | ||
galera | ||
galera_3nodes | ||
galera_3nodes_sr | ||
galera_sr | ||
gcol | ||
handler | ||
heap | ||
innodb | ||
innodb_fts | ||
innodb_gis | ||
innodb_i_s | ||
innodb_zip | ||
jp | ||
json | ||
large_tests | ||
maria | ||
mariabackup | ||
mtr/t | ||
mtr2 | ||
multi_source | ||
optimizer_unfixed_bugs | ||
parts | ||
perfschema | ||
perfschema_stress | ||
period | ||
plugins | ||
roles | ||
rpl | ||
s3 | ||
sql_sequence | ||
storage_engine | ||
stress | ||
sys_vars | ||
unit | ||
vcol | ||
versioning | ||
wsrep |