Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-33441

No spider variables available is Spider is loaded upon server startup

Details

    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).

      Attachments

        Activity

          ycp Yuchen Pei added a comment -

          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

          ycp Yuchen Pei added a comment - 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

          Looks good, thanks.

          We don't have many debug builders, include/have_debug.inc reduces the number of builders that will run the test about 10x. That is, if you can make spider initialization to fail without DBUG_EXECUTE_IF, it'd be preferable. Like, create a view with a name of a reserved spider table, create a file (mysqltest can do it) where spider expects a table, invalid value for a spider command line option, etc. But I wasn't able to see how it's possible to fail spider initialization without debug. So, anyway, either is ok to push.

          serg Sergei Golubchik added a comment - Looks good, thanks. We don't have many debug builders, include/have_debug.inc reduces the number of builders that will run the test about 10x. That is, if you can make spider initialization to fail without DBUG_EXECUTE_IF , it'd be preferable. Like, create a view with a name of a reserved spider table, create a file (mysqltest can do it) where spider expects a table, invalid value for a spider command line option, etc. But I wasn't able to see how it's possible to fail spider initialization without debug. So, anyway, either is ok to push.
          ycp Yuchen Pei added a comment - - edited

          Thanks for the review serg, could you push the commit 59af46e79dec292f8b03c31aee8444fc0485dad3 to 10.4 for me, since 10.4 is locked?

          In case you want to save some time waiting for the CI, I have it rebased to the current 10.4 at

          5f5fd4a6a71 upstream/bb-10.4-mdev-33441 MDEV-33441 Do not deinit plugin variables when retry requested

          ycp Yuchen Pei added a comment - - edited Thanks for the review serg , could you push the commit 59af46e79dec292f8b03c31aee8444fc0485dad3 to 10.4 for me, since 10.4 is locked? In case you want to save some time waiting for the CI, I have it rebased to the current 10.4 at 5f5fd4a6a71 upstream/bb-10.4-mdev-33441 MDEV-33441 Do not deinit plugin variables when retry requested

          ycp I will push it

          sanja Oleksandr Byelkin added a comment - ycp I will push it

          The bug was fixed between 10.4-11.2 was issued and 11.3-11.4 was not. so it got (because of importance) in "old" 11.3 and 11.4 versions.

          sanja Oleksandr Byelkin added a comment - The bug was fixed between 10.4-11.2 was issued and 11.3-11.4 was not. so it got (because of importance) in "old" 11.3 and 11.4 versions.

          People

            ycp Yuchen Pei
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.