| Bug #107161 | table_open_cache calculation seems wrong in document | ||
|---|---|---|---|
| Submitted: | 29 Apr 2022 9:20 | Modified: | 13 May 2022 20:36 |
| Reporter: | Kei Aoyama | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
| Version: | 5.6,5.7,8.0 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[29 Apr 2022 9:32]
MySQL Verification Team
Hello Kei Sato, Thank you for the report and feedback. regards, Umesh
[13 May 2022 20:36]
Jon Stephens
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly.
Description: The calculation of table_open_cache is different from the actual behavior. current document: MAX( open_files_limit - 10 - (max_connections / 2), 400 ) https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_table_open_cac... https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_table_open_cac... actual behavior: 5606 limit= max<ulong>((requested_open_files - 10 - max_connections) / 2, 5607 TABLE_OPEN_CACHE_MIN); https://github.com/mysql/mysql-server/blob/afb74f1/sql/mysqld.cc#L5606-L5607 The actual behavior is based on MAX((open_files_limit - 10 - max_connections) / 2, 400), which is different from the document. How to repeat: Read the code and the document above. Suggested fix: Verify which is the expected behavior and correct the wrong one.