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

legacy_db_type needs rethinking

Details

    • Task
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • None

    Description

      With every major release DB_TYPE_FIRST_DYNAMIC changes so dynamic engine plugins shift IDs with it. FRM files are not automatically updated which can cause issues in code that uses these IDs.

      For example in 10.2 an engine will have ID 44, in 10.3 ID 44 is reserved for DB_TYPE_SEQUENCE. When a TRUNCATE is called after an upgrade MariaDB calls certain functions in the SEQUENCE engine instead of the intended engine plugin which can cause a crash.

      The only workaround appears to be "ALTER TABLE comment=''"

      There are several ways this could be solved. mysql_upgrade should probably be aware of this. Maybe the start ID for legacy_db_type should be something high like 100?

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MCOL-3673 Proper fix for db_type issues

          • Major - Major loss of function.
          • Closed

          Task - A task that needs to be done. MDEV-18772 fix DB_TYPE_FIRST_DYNAMIC

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. MCOL-2061 MariaDB shows warnings and could crash on DDL after upgrade

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik added a comment -

            all new frms store the engine name, the server doesn't have to trust frm's legacy_db_type. On the opposite, it can assume that it's wrong and infer it from the engine name when the frm is opened.

            serg Sergei Golubchik added a comment - all new frms store the engine name , the server doesn't have to trust frm's legacy_db_type. On the opposite, it can assume that it's wrong and infer it from the engine name when the frm is opened.
            Richard Richard Stracke added a comment -

            The same issue exists with spider engine.

            "ALTER TABLE comment=''" is not an option, because important information will be stored in the comment field for spider.

            A modified version of columnstore_upgrade for spider could be based on alter table engine = spider like

            DELIMITER //
            		 
             
            		 
            create procedure spider_upgrade()
            		 
            `spider_upgrade`: BEGIN
            		 
             DECLARE done INTEGER DEFAULT 0;
            		 
                DECLARE schema_table VARCHAR(100) CHARACTER SET utf8 DEFAULT "";
            		 
                DECLARE table_list CURSOR FOR select concat('`', table_schema,'`.`',table_name,'`') from information_schema.tables where engine='spider';
            		 
                DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
            		 
                OPEN table_list;
            		 
                tlist: LOOP
            		 
                    FETCH table_list INTO schema_table;
            		 
                    IF done = 1 THEN LEAVE tlist;
            		 
                    END IF;
            		 
                    SET @sql_query = concat('ALTER TABLE ', schema_table, ' engine=spider');
            		 
                    PREPARE stmt FROM @sql_query;
            		 
                    EXECUTE stmt;
            		 
                    DEALLOCATE PREPARE stmt;
            		 
                END LOOP;
            		 
            END //
            		 
             
            		 
            DELIMITER ;

            Richard Richard Stracke added a comment - The same issue exists with spider engine. "ALTER TABLE comment=''" is not an option, because important information will be stored in the comment field for spider. A modified version of columnstore_upgrade for spider could be based on alter table engine = spider like DELIMITER //   create procedure spider_upgrade() `spider_upgrade`: BEGIN DECLARE done INTEGER DEFAULT 0 ; DECLARE schema_table VARCHAR( 100 ) CHARACTER SET utf8 DEFAULT "" ; DECLARE table_list CURSOR FOR select concat( '`' , table_schema, '`.`' ,table_name, '`' ) from information_schema.tables where engine= 'spider' ; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1 ; OPEN table_list; tlist: LOOP FETCH table_list INTO schema_table; IF done = 1 THEN LEAVE tlist; END IF; SET @sql_query = concat( 'ALTER TABLE ' , schema_table, ' engine=spider' ); PREPARE stmt FROM @sql_query ; EXECUTE stmt; DEALLOCATE PREPARE stmt; END LOOP; END //   DELIMITER ;
            nikitamalyavin Nikita Malyavin added a comment -

            So what am I supposed to do in this "bug"?

            nikitamalyavin Nikita Malyavin added a comment - So what am I supposed to do in this "bug"?
            serg Sergei Golubchik added a comment -

            it was incorrectly reported as a bug, looks more like a refactoring task to me. changed.

            serg Sergei Golubchik added a comment - it was incorrectly reported as a bug, looks more like a refactoring task to me. changed.

            People

              nikitamalyavin Nikita Malyavin
              LinuxJedi Andrew Hutchings (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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