Kristofer Pettersson afee63222a Bug#19027 MySQL 5.0 starts even with Fatal InnoDB errors ...

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.

2009-05-14 14:03:33 +02:00

5.3 KiB

Raw Blame History

View Raw