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.