Bug #44954 PerformanceSchema: --performance-schema-max-thread=0 has strange effects
Submitted: 19 May 2009 14:03 Modified: 24 Jul 2009 19:37
Reporter: Guilhem Bichot Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Performance Schema Severity:S3 (Non-critical)
Version:6.0-perfschema OS:Linux (64bit)
Assigned to: Marc Alff CPU Architecture:Any
Triage: Triaged: D3 (Medium)

[19 May 2009 14:03] Guilhem Bichot
Description:
I could not exactly set this option but I changed, in mysqld.cc:
  pfs_param.m_thread_sizing= PFS_MAX_THREAD;
to
  pfs_param.m_thread_sizing= 0; // PFS_MAX_THREAD;
Then I ran
 ./mtr --mem --suite=perfschema --force --max-test-fail=0
and observed things which I cannot explain:
CURRENT_TEST: perfschema.binlog_row
mysqltest: At line 27: query 'update performance_schema.SETUP_INSTRUMENTS set enabled='NO'' failed: 1031: Table storage engine for 'SETUP_INSTRUMENTS' doesn't have this option

CURRENT_TEST: perfschema.server_init
--- /home/mysql_src/bzrrepos/mysql-6.0-perfschema/mysql-test/suite/perfschema/r/server_init.result	2009-05-07 11:23:07.000000000 +0300
+++ /home/mysql_src/bzrrepos/mysql-6.0-perfschema/mysql-test/suite/perfschema/r/server_init.reject	2009-05-19 16:56:51.000000000 +0300
@@ -2,276 +2,276 @@
 select count(name) from MUTEX_INSTANCES
 where name like "wait/synch/mutex/mysys/THR_LOCK_threads";
 count(name)
-1
+0

CURRENT_TEST: perfschema.ddl_cond_instances
mysqltest: At line 25: query 'truncate table performance_schema.COND_INSTANCES' succeeded - should have failed with errno 1031...

How to repeat:
see description
[28 May 2009 11:37] Guilhem Bichot
Based on Guilhem's reply to Marc's comments, setting to Verified again, until a reply is received.

If --max-threads=0 is meaningless, please forbid the user from setting this. For example by changing the last line of
  {"performance_schema_max_thread", OPT_PFS_MAX_THREAD,
   "Maximum number of instrumented threads.",
   (uchar**) &pfs_param.m_thread_sizing,
   (uchar**) &pfs_param.m_thread_sizing,
   NULL, GET_ULONG, OPT_ARG, PFS_MAX_THREAD, 0, ULONG_MAX, 0, 1, NULL},
to
   NULL, GET_ULONG, OPT_ARG, PFS_MAX_THREAD, X, ULONG_MAX, 0, 1, NULL},
where X is the minimum value which is meaningful (1?).
[24 Jul 2009 19:37] Marc Alff
The following options:
--performance_schema_max_thread_classes=0
--performance_schema_max_thread_instances=0
are legal, and are covered by the various tests for the performance schema,
so no code should be changed here.

See in particular start_server*.test and start_server*.opt

I can not reproduce the "strange effects" originally reported,
so this bug report is closed as can't repeat.

Should this report be re-opened, please provide a test script to expose the bug, that uses a *non modified* server.
[27 Jul 2009 11:17] Guilhem Bichot
Indeed, with the latest azalea-perfschema I don't see the strange UPDATE error in perfschema.binlog_row, so I agree that this can be closed.