Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.4(EOL), 10.5, 10.6, 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL), 11.3(EOL), 11.4
Description
Run in MTR with --mysqld=--plugin-load-add=ha_spider (or start the server with the option) and run in the client.
show engines;
|
show variables like 'spider%'; |
10.4 23101304887e9e1987c45f001377382e3fdfd88f |
Engine Support Comment Transactions XA Savepoints
|
SPIDER YES Spider storage engine YES YES NO |
...
|
|
show variables like 'spider%'; |
Variable_name Value
|
No variables. If however spider is installed at runtime via INSTALL SONAME, then variables are loaded.
Run without plugin-load-add=ha_spider:
Variable_name Value
|
spider_auto_increment_mode 0
|
spider_bgs_first_read 2
|
<... many more...>
|
spider_wait_timeout 604800
|
spider_xa_register_mode 1
|
This is a regression from the previous release set (unless on some reason it is intentional).
Hi serg, ptal thanks
upstream/bb-10.4-mdev-33441 59af46e79dec292f8b03c31aee8444fc0485dad3
MDEV-33441 Do not deinit plugin variables when retry requested
After MDEV-31400, plugins are allowed to ask for retries when failing
initialisation. However, such failures also cause plugin system
variables to be deleted (plugin_variables_deinit()) before retrying
and are not re-added during retry.
We fix this by checking that if the plugin has requested a retry the
variables are not deleted. Because plugin_deinitialize() also calls
plugin_variables_deinit(), if the retry fails, the variables will
still be deleted.
Alternatives considered:
- remove the plugin_variables_deinit() from plugin_initialize() error
handling altogether. We decide to take a more conservative approach
here.
- re-add the system variables during retry. It is more complicated
than simply iterating over plugin->system_vars and call
my_hash_insert(). For example we will need to assign values to
the test_load field and extract more code from test_plugin_options(),
if that is possible.
I'm testing 10.6 as the spider init is a bit different because of the ddl logs, but I don't expect any issues