| 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: | |
| Category: | MySQL Server: Performance Schema | Severity: | S3 (Non-critical) | 
| Version: | 6.0-perfschema | OS: | Linux (64bit) | 
| Assigned to: | Marc ALFF | CPU Architecture: | Any | 
   [19 May 2009 14:03]
   Guilhem Bichot        
  
 
   [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.

