mirror of
https://github.com/MariaDB/server.git
synced 2025-01-31 11:01:52 +01:00
a53f3c6d3c
(Fixing both InnoDB and XtraDB) Re-opening a TABLE object (after e.g. FLUSH TABLES or open table cache eviction) causes ha_innobase to call dict_stats_update(DICT_STATS_FETCH_ONLY_IF_NOT_IN_MEMORY). Inside this call, the following is done: dict_stats_empty_table(table); dict_stats_copy(table, t); On the other hand, commands like UPDATE make this call to get the "rows in table" statistics in table->stats.records: ha_innobase->info(HA_STATUS_VARIABLE|HA_STATUS_NO_LOCK) note the HA_STATUS_NO_LOCK parameter. It means, no locks are taken by ::info() If the ::info() call happens between dict_stats_empty_table and dict_stats_copy calls, the UPDATE's optimizer will get an estimate of table->stats.records=1, which causes it to pick a full table scan, which in turn will take a lot of row locks and cause other bad consequences. |
||
|---|---|---|
| .. | ||
| dict0boot.cc | ||
| dict0crea.cc | ||
| dict0dict.cc | ||
| dict0load.cc | ||
| dict0mem.cc | ||
| dict0stats.cc | ||
| dict0stats_bg.cc | ||