Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6
-
None
Description
Performance_schema data related to instrument "wait/synch/mutex/threadpool/group_mutex" is incorrect.
How to reproduce:
1. Start a mariadb instance with threadpool and performance_schema both enabled: --thread-handling=pool-of-threads --performance-schema=ON
2. Enable the instrument in performance_schema: CALL sys.ps_setup_enable_instrument('wait/synch/mutex/threadpool/group_mutex');
3. Send any queries to change the instrument's counters, e.g. select * from `performance_schema`.events_waits_summary_global_by_event_name;
4. Verity the bug:
- All counters are zero in the result of the following SQL, while expected to be greater than zero: select * from `performance_schema`.events_waits_summary_global_by_event_name where event_name = 'wait/synch/mutex/threadpool/group_mutex';
- The number of group_mutex instance is zero in the result of the following SQL, while expected to be equal to the thread_pool_size: select count(*) from `performance_schema`.mutex_instances where name like 'wait/synch/mutex/threadpool/group_mutex';
Root cause:
The "group_mutex" is expected to be registered and then initialized in TP_pool_generic::init in threadpool_generic.cc. However, initialization was wrongly put before register, specifically the code line thread_group_init before PSI_register(mutex).
How to fix:
Put PSI_register before thread_group_init. I've created a patch in this pull request.