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

Assertion `!omits_virtual_cols(*form->s)' failed after upgrade from 10.0/10.1 with PERSISTENT generated column

Details

    Description

      To reproduce,

      • On 10.0/10.1 with all default options, run 

        create table t1 (a int, b int generated always as (a) persistent) engine=InnoDB;

      • shut down the server normally;
      • start 10.2+ on the same datadir;
      • [optionally] run mysql_upgrade (doesn't make any difference for the failure on TRUNCATE, but see the footnote);
      • run 

        truncate table t1;

      10.4 09b2d37a

      		 
      mysqld: /data/src/10.4/storage/innobase/handler/ha_innodb.cc:10733: bool create_table_check_doc_id_col(trx_t*, const TABLE*, ulint*): Assertion `!omits_virtual_cols(*form->s)' failed.
      		 
      190318 20:23:53 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f410c1ccee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      		 
      #8  0x0000560e1fd64ec4 in create_table_check_doc_id_col (trx=0x7f4108eda390, form=0x7f409806fe80, doc_id_col=0x7f4108e3f8e8) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:10733
      		 
      #9  0x0000560e1fd7a4f7 in create_table_info_t::create_table_def (this=0x7f4108e3fd60) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:10963
      		 
      #10 0x0000560e1fd6744f in create_table_info_t::create_table (this=0x7f4108e3fd60, create_fk=false) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:12401
      		 
      #11 0x0000560e1fd7bcb8 in ha_innobase::create (this=0x7f40981ca5d8, name=0x7f40982f24a0 "test/t1", form=0x7f409806fe80, create_info=0x7f4108e40270, file_per_table=true, trx=0x7f4108eda390) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:12719
      		 
      #12 0x0000560e1fd68f13 in ha_innobase::truncate (this=0x7f40981ca5d8) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:13393
      		 
      #13 0x0000560e1fa24e05 in handler::ha_truncate (this=0x7f40981ca5d8) at /data/src/10.4/sql/handler.cc:4562
      		 
      #14 0x0000560e1f882b20 in Sql_cmd_truncate_table::handler_truncate (this=0x7f4098014a00, thd=0x7f4098000b00, table_ref=0x7f4098014358, is_tmp_table=false) at /data/src/10.4/sql/sql_truncate.cc:242
      		 
      #15 0x0000560e1f88325a in Sql_cmd_truncate_table::truncate_table (this=0x7f4098014a00, thd=0x7f4098000b00, table_ref=0x7f4098014358) at /data/src/10.4/sql/sql_truncate.cc:450
      		 
      #16 0x0000560e1f8833e8 in Sql_cmd_truncate_table::execute (this=0x7f4098014a00, thd=0x7f4098000b00) at /data/src/10.4/sql/sql_truncate.cc:506
      		 
      #17 0x0000560e1f6de4dc in mysql_execute_command (thd=0x7f4098000b00) at /data/src/10.4/sql/sql_parse.cc:6394
      		 
      #18 0x0000560e1f6e3675 in mysql_parse (thd=0x7f4098000b00, rawbuf=0x7f4098014288 "truncate table test.t1", length=22, parser_state=0x7f4108e411d0, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8205
      		 
      #19 0x0000560e1f6ceca5 in dispatch_command (command=COM_QUERY, thd=0x7f4098000b00, packet=0x7f409801c361 "truncate table test.t1", packet_length=22, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1829
      		 
      #20 0x0000560e1f6cd48b in do_command (thd=0x7f4098000b00) at /data/src/10.4/sql/sql_parse.cc:1358
      		 
      #21 0x0000560e1f847387 in do_handle_one_connection (connect=0x560e23a13e90) at /data/src/10.4/sql/sql_connect.cc:1399
      		 
      #22 0x0000560e1f8470f8 in handle_one_connection (arg=0x560e23a13e90) at /data/src/10.4/sql/sql_connect.cc:1302
      		 
      #23 0x00007f410dea3494 in start_thread (arg=0x7f4108e42700) at pthread_create.c:333
      		 
      #24 0x00007f410c28993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

      Footnote

      If truncate table was run and crashed without previous mysql_upgrade, 10.3/10.4 refuse to start afterwards:

      mysqld: /data/src/10.4/storage/innobase/row/row0undo.cc:389: bool row_undo_rec_get(undo_node_t*): Assertion `undo == update || undo == temp' failed.
      		 
      190318 20:32:51 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007fa3b6936ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      		 
      #8  0x000056153f1d6025 in row_undo_rec_get (node=0x561542c2ed38) at /data/src/10.4/storage/innobase/row/row0undo.cc:389
      		 
      #9  0x000056153f1d614e in row_undo (node=0x561542c2ed38, thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/row/row0undo.cc:414
      		 
      #10 0x000056153f1d6424 in row_undo_step (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/row/row0undo.cc:498
      		 
      #11 0x000056153f1368b2 in que_thr_step (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/que/que0que.cc:1040
      		 
      #12 0x000056153f136b01 in que_run_threads_low (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/que/que0que.cc:1104
      		 
      #13 0x000056153f136cf2 in que_run_threads (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/que/que0que.cc:1144
      		 
      #14 0x000056153f234e9c in trx_rollback_active (trx=0x7fa3a10dd140) at /data/src/10.4/storage/innobase/trx/trx0roll.cc:663
      		 
      #15 0x000056153f23568b in trx_rollback_recovered (all=false) at /data/src/10.4/storage/innobase/trx/trx0roll.cc:819
      		 
      #16 0x000056153f1fc395 in srv_start (create_new_db=false) at /data/src/10.4/storage/innobase/srv/srv0start.cc:2114
      		 
      #17 0x000056153f022a58 in innodb_init (p=0x561541cd35f0) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:4285
      		 
      #18 0x000056153ece6ed9 in ha_initialize_handlerton (plugin=0x561541cc4878) at /data/src/10.4/sql/handler.cc:531
      		 
      #19 0x000056153e9bb92b in plugin_initialize (tmp_root=0x7ffc511e5960, plugin=0x561541cc4878, argc=0x561540226078 <remaining_argc>, argv=0x561541c61d68, options_only=false) at /data/src/10.4/sql/sql_plugin.cc:1437
      		 
      #20 0x000056153e9bc5c0 in plugin_init (argc=0x561540226078 <remaining_argc>, argv=0x561541c61d68, flags=2) at /data/src/10.4/sql/sql_plugin.cc:1720
      		 
      #21 0x000056153e86dbf9 in init_server_components () at /data/src/10.4/sql/mysqld.cc:5176
      		 
      #22 0x000056153e86eddf in mysqld_main (argc=11, argv=0x561541c61d68) at /data/src/10.4/sql/mysqld.cc:5703
      		 
      #23 0x000056153e863460 in main (argc=11, argv=0x7ffc511e63a8) at /data/src/10.4/sql/main.cc:25

      (Possibly it's not mysql_upgrade as such that's important, but any activity before truncate).

      Data directory pre-created on 10.1 cd805a5f is attached as data.tar.gz.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-13564 TRUNCATE TABLE and undo tablespace truncation are not compatible with Mariabackup

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17199 Assertion `pos < table->n_v_def' failed in dict_table_get_nth_v_col after upgrade from 10.1/10.0 to 10.2

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-18966 Transaction recovery may be broken after upgrade to 10.3

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            The assertion that was added in MDEV-17199 is conflicting with the TRUNCATE TABLE implementation of MDEV-13564. Because the .frm file will not change in TRUNCATE, InnoDB must be prepared to create a table with ‘old-format’ metadata.

            When the failing assertion is removed, the TRUNCATE will proceed without a crash. Alas, if we define a slightly different table before upgrading, the table would fail to load after TRUNCATE:

            create table t2 (a int, b int as (a) virtual) engine=innodb;
            		 
            --echo # upgrade to 10.2+
            		 
            truncate table t2;

            This would lead to an error message being issued to the client:

            ERROR 1932 (42S02): Table 'test.t2' doesn't exist in engine

            and another message being emitted to the server error log:

            2019-03-19 9:33:28 8 [Warning] InnoDB: Table test/t2 contains 2 user defined columns in InnoDB, but 1 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

            When it comes to the 10.3 assertion failure after the initial crash, it appears that the trx->rsegs.m_redo.undo that the TRUNCATE transaction did write before the server crashed was incorrectly recovered as trx->rsegs.m_redo.old_insert. This could be a regression that affects any upgrade to 10.3. Basically, a follow-up fix to MDEV-12288 is needed. MDEV-15912 documents another such problem.

            marko Marko Mäkelä added a comment - The assertion that was added in MDEV-17199 is conflicting with the TRUNCATE TABLE implementation of MDEV-13564 . Because the .frm file will not change in TRUNCATE , InnoDB must be prepared to create a table with ‘old-format’ metadata. When the failing assertion is removed, the TRUNCATE will proceed without a crash. Alas, if we define a slightly different table before upgrading, the table would fail to load after TRUNCATE : create table t2 (a int , b int as (a) virtual) engine=innodb; --echo # upgrade to 10.2+ truncate table t2; This would lead to an error message being issued to the client: ERROR 1932 (42S02): Table 'test.t2' doesn't exist in engine and another message being emitted to the server error log: 2019-03-19 9:33:28 8 [Warning] InnoDB: Table test/t2 contains 2 user defined columns in InnoDB, but 1 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue. When it comes to the 10.3 assertion failure after the initial crash, it appears that the trx->rsegs.m_redo.undo that the TRUNCATE transaction did write before the server crashed was incorrectly recovered as trx->rsegs.m_redo.old_insert . This could be a regression that affects any upgrade to 10.3. Basically, a follow-up fix to MDEV-12288 is needed. MDEV-15912 documents another such problem.
            marko Marko Mäkelä added a comment -

            I filed MDEV-18966 for the 10.3+ recovery problem.

            marko Marko Mäkelä added a comment - I filed MDEV-18966 for the 10.3+ recovery problem.

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.