• Kristofer Pettersson's avatar
    Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors · afee6322
    Kristofer Pettersson authored
    It is not possible to prevent the server from starting if a mandatory
    built-in plugin fails to start. This can in some cases lead to data
    corruption when the old table name space suddenly is used by a different
    storage engine.
    
    A boolean command line option in the form of --foobar is automatically
    created for every existing plugin "foobar". By changing this command line
    option from a boolean to a tristate { OFF, ON, FORCE } it is possible to
    specify the plugin loading policy for each plugin.
    
    The behavior is specified as follows:
       OFF   = Disable the plugin and start the server
       ON    = Enable the plugin and start the server even if an error occurrs
               during plugin initialization.
       FORCE = Enable the plugin but don't start the server if an error occurrs
               during plugin initialization.
    
    
    mysql-test/lib/mtr_cases.pm:
      * Changed --<pluginname> from a boolean to a tristate.
    mysys/my_getopt.c:
      * Changed --<pluginname> from boolean to tristate. Optional arguments
        must still work for tristates. It is praxis that disable means value 0
        and enable is value 1. Since plugin name is the only tristate with
        optional arguments this principle will still hold.
    sql/sql_plugin.cc:
      * Changed --<pluginname> option from a boolean type to a tristate.
        - FORCE will now terminate the server if the plugin fails to
          initialize properly.
      * Refactored prototypes for test_plugin_options() and construct_options()
        to get rid of the 'enable' value pointer.
      * Cleaned up code related to option name constructing.
      * Added documentation
    sql/sql_plugin.h:
      * Introduced new member to st_plugin_int structure.
    afee6322
my_getopt.c 35.5 KB