Multiple issues with performance_schema_max_statement_classes

Bug #1157075 reported by Alexey Kopytov on 2013-03-19
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL Server
Percona Server
Sergei Glushchenko
Sergei Glushchenko

Bug Description

Reporting against Percona Server, as we have to fix it in one way or another until an upstream fix is implemented:

The manual states the following about performance_schema_max_statement_classes:

- it is "The maximum number of statement instruments."
- its default value is 100.


1. The default value is wrong. On 5.6.10 the default value is 167

2. The default value is automatically calculated at compile time based on the number of protocol commands and SQL statement types supported by the server.

3. That automatically calculated value is enforced by 83 tests in the test suite. Which makes introducing and maintaining new commands or statement types a nightmare. Whenever a new command/type is added, one has to update 83 totally unrelated test cases. Is it possible to change the default to a sufficiently large constant and thus not introduce additional maintenance work for other MySQL branches?

4. The effect of changing that variable is absolutely unclear from the docs. What happens when it's set to a lower value than the automatically calculated default? What happens when it's set to a higher (e.g. the maximum allowed) value?

Related branches

Looks like majority of tests which affected by this option have it's own -master.opt, so every test should be fixed individually.

Setting loose-performance-schema-max-statement-classes=167 in default_mysqld.cnf breaks many *aggregate* tests.

Alexey Kopytov (akopytov) wrote :

Sergei, can you provide any details on aggregate test failures?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.