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.
Attachments
Activity
Field | Original Value | New Value |
---|---|---|
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 as 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. |
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 as 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. |
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 as 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. |
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 as 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 [PR|https://github.com/MariaDB/server/pull/1867] |
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 as 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 [PR|https://github.com/MariaDB/server/pull/1867] |
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 as 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|https://github.com/MariaDB/server/pull/1867] |
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 as 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|https://github.com/MariaDB/server/pull/1867] |
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 as 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|https://github.com/MariaDB/server/pull/1867]. |
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 as 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|https://github.com/MariaDB/server/pull/1867]. |
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|https://github.com/MariaDB/server/pull/1867]. |
Assignee | Vladislav Vaintroub [ wlad ] |
Fix Version/s | 10.5 [ 23123 ] | |
Fix Version/s | 10.6 [ 24028 ] |
Priority | Minor [ 4 ] | Major [ 3 ] |
Status | Open [ 1 ] | Confirmed [ 10101 ] |
Fix Version/s | 10.5.12 [ 26025 ] | |
Fix Version/s | 10.6.4 [ 26033 ] | |
Fix Version/s | 10.5 [ 23123 ] | |
Fix Version/s | 10.6 [ 24028 ] | |
Resolution | Fixed [ 1 ] | |
Status | Confirmed [ 10101 ] | Closed [ 6 ] |
Workflow | MariaDB v3 [ 123102 ] | MariaDB v4 [ 159459 ] |