Description:
I learned about bug#115517 from Percona's blog, which is a serious problem that has not been fully tested.
In fact, the cause of the bug is very simple: when the number exceeds 8000, InnoDB will call multiple threads to perform checks, and the THD of threads other than the main thread is not initialized, resulting in abnormal access to DD in the fix introduced by commit#28eb1ff.
But I want to talk about other problems.
1. This is a concurrent function, but the test case does not cover it.
2. The rationality of such a design is questionable. I have done a lot of tests and research on the startup of MySQL InnoDB massive tables. It is not a very fast behavior to obtain DD information. Take my test data as an example:
1 million tables (sysbench construction), normal shutdown and restart, the startup time is as follows:
Tablespace_dirs::scan() - 44.4s
fetch_global_components(&tablespaces) - 25.5s
validate(tablespaces) - 15.8
Total - 90.7
We can find that fetch_global_components(&tablespaces) occupies 28% of the startup time, and this function is to read the DD::tablespace table and build the DD::tablespace object.
After introducing commit#28eb1ff, ignoring bug#115517, we can assume that in addition to obtaining all tablespaces, we also need to obtain all DD::tables. And unlike the acquisition of DD::tablespace, the acquisition of DD::table will be more resource-intensive, because each acquisition requires the construction and destruction of the Auto_releaser object. (Although multithreading is introduced, I think the problem still exists).
3. For the function dict_name::parse_tablespace_path, I think this function deserves a separate discussion:
3.1 I don't think it is reasonable to pass std::string path to the function. I think const std::string &path is more appropriate.
3.2 SUB_PART_SEPARATOR and PART_SEPARATOR are used in the function, but due to historical reasons, the separators of partitions and subpartitions may also be #P# #SP#. Obviously, this function cannot handle this problem. Let's go back to the Validate_files::check function. After parse_tablespace_path, fil_update_partition_name is actually called to handle the partition separator problem I mentioned above. Therefore, the design and use of dict_name::parse_tablespace_path are not entirely reasonable.
How to repeat:
This is a discussion about bug#115517
