-
Marc Alff authored
Before this fix, For a server compiled with performance schema support, when starting the server with the performance schema disabled at startup time, as in: performance_schema = OFF the server would fail to create performance_schema tables, which in turn causes the creation of views provided by sysschema to fail. The root cause is as follows: - during the server startup, the code detects that the performance schema is not initialized. - the variable load_perfschema_engine stays as false as a result - later, when loading the performance schema plugin, the plugin is loaded with the option PLUGIN_OFF (aka, not loaded) - during the database initialization in mysql_system_tables.sql, the scripts looks for entries in table information_schema.engines, and finds none, leading the script to assume the server is not compiled with performance schema support. - performance schema tables are not created during the install. - installation of the sysschema views fail. The fix is to simplify and streamline the entire process, which is too convoluted. In particular, - a server compiled with performance schema support always load the performance schema engine, now mandatory, regardless of the runtime configuration. - a server compiled with performance schema support always create the performance schema tables during install. The database layout of the installed product should depend only on build options (to compile with of without the performance schema), and never depend on runtime configurations options (to start the server with or without instrumentation) When the performance schema is not used during server startup, no data will be collected and no memory allocated, so there is no performance impact: there are no changes here. The only change is to always create performance schema tables when the server is compiled with performance schema support.
Marc Alff authoredBefore this fix, For a server compiled with performance schema support, when starting the server with the performance schema disabled at startup time, as in: performance_schema = OFF the server would fail to create performance_schema tables, which in turn causes the creation of views provided by sysschema to fail. The root cause is as follows: - during the server startup, the code detects that the performance schema is not initialized. - the variable load_perfschema_engine stays as false as a result - later, when loading the performance schema plugin, the plugin is loaded with the option PLUGIN_OFF (aka, not loaded) - during the database initialization in mysql_system_tables.sql, the scripts looks for entries in table information_schema.engines, and finds none, leading the script to assume the server is not compiled with performance schema support. - performance schema tables are not created during the install. - installation of the sysschema views fail. The fix is to simplify and streamline the entire process, which is too convoluted. In particular, - a server compiled with performance schema support always load the performance schema engine, now mandatory, regardless of the runtime configuration. - a server compiled with performance schema support always create the performance schema tables during install. The database layout of the installed product should depend only on build options (to compile with of without the performance schema), and never depend on runtime configurations options (to start the server with or without instrumentation) When the performance schema is not used during server startup, no data will be collected and no memory allocated, so there is no performance impact: there are no changes here. The only change is to always create performance schema tables when the server is compiled with performance schema support.
Loading