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

Assertion `0' failed in row_log_table_apply_op after instant ADD when the table is emptied during subsequent ALTER TABLE

    XMLWordPrintable

    Details

      Description

      Note: run the test case with --mem --repeat=N. For me N=100 has always been enough so far, but it can vary on different machines. --mem is important, at least on my machines, apparently the test is not fast/concurrent enough when it's run on disk.

      --source include/have_innodb.inc
       
      --disable_abort_on_error
       
      CREATE TABLE t1 (a INT) ENGINE=InnoDB;
      INSERT INTO t1 VALUES (NULL),(NULL);
      ALTER TABLE t1 ADD COLUMN b INT;
      ALTER TABLE t1 ADD UNIQUE KEY uidx (b);
       
      --connect (con1,localhost,root,,test)
      --send
      	ALTER TABLE t1 DROP COLUMN b;
       
      --connection default
      DELETE FROM t1;
      INSERT INTO t1 (b) VALUES (1),(1);
       
      # Cleanup
      --connection con1
      --reap
      --disconnect con1
      --connection default
      DROP TABLE t1;
      

      10.3 cb16bc95ff

      mysqld: /data/src/10.3/storage/innobase/row/row0log.cc:2435: const mrec_t* row_log_table_apply_op(que_thr_t*, ulint, row_merge_dup_t*, dberr_t*, mem_heap_t*, mem_heap_t*, const mrec_t*, const mrec_t*, ulint*): Assertion `0' failed.
      180430 18:12:25 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f48b64a0ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x000055bf625b97d3 in row_log_table_apply_op (thr=0x7f48600771c8, new_trx_id_col=1, dup=0x7f48ab74fd80, error=0x7f48ab74fb2c, offsets_heap=0x7f486003fe60, heap=0x7f486003bdd0, mrec=0x7f48ab60c021 "", mrec_end=0x7f48ab60c06c "", offsets=0x7f48600358c0) at /data/src/10.3/storage/innobase/row/row0log.cc:2435
      #9  0x000055bf625bbd36 in row_log_table_apply_ops (thr=0x7f48600771c8, dup=0x7f48ab74fd80, stage=0x7f4860038100) at /data/src/10.3/storage/innobase/row/row0log.cc:3046
      #10 0x000055bf625bc2ee in row_log_table_apply (thr=0x7f48600771c8, old_table=0x7f485c03c1e8, table=0x7f48600d48b0, stage=0x7f4860038100) at /data/src/10.3/storage/innobase/row/row0log.cc:3146
      #11 0x000055bf62495fdf in commit_try_rebuild (ha_alter_info=0x7f48ab7513f0, ctx=0x7f4860014e88, altered_table=0x7f48600d48b0, old_table=0x7f485c085b70, trx=0x7f48b02dcac8, table_name=0x7f485c08a185 "t1") at /data/src/10.3/storage/innobase/handler/handler0alter.cc:8439
      #12 0x000055bf62490618 in ha_innobase::commit_inplace_alter_table (this=0x7f485c087368, altered_table=0x7f48600d48b0, ha_alter_info=0x7f48ab7513f0, commit=true) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:9314
      #13 0x000055bf62138de6 in handler::ha_commit_inplace_alter_table (this=0x7f485c087368, altered_table=0x7f48600d48b0, ha_alter_info=0x7f48ab7513f0, commit=true) at /data/src/10.3/sql/handler.cc:4406
      #14 0x000055bf61f23d58 in mysql_inplace_alter_table (thd=0x7f4860000b00, table_list=0x7f4860013bd8, table=0x7f485c085b70, altered_table=0x7f48600d48b0, ha_alter_info=0x7f48ab7513f0, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7f48ab751460, alter_ctx=0x7f48ab752060) at /data/src/10.3/sql/sql_table.cc:7535
      #15 0x000055bf61f29c3f in mysql_alter_table (thd=0x7f4860000b00, new_db=0x7f4860005168, new_name=0x7f4860005518, create_info=0x7f48ab752c50, table_list=0x7f4860013bd8, alter_info=0x7f48ab752b90, order_num=0, order=0x0, ignore=false) at /data/src/10.3/sql/sql_table.cc:9670
      #16 0x000055bf61faf0fc in Sql_cmd_alter_table::execute (this=0x7f4860014258, thd=0x7f4860000b00) at /data/src/10.3/sql/sql_alter.cc:334
      #17 0x000055bf61e55f79 in mysql_execute_command (thd=0x7f4860000b00) at /data/src/10.3/sql/sql_parse.cc:6282
      #18 0x000055bf61e5aa46 in mysql_parse (thd=0x7f4860000b00, rawbuf=0x7f4860013af0 "ALTER TABLE t1 DROP COLUMN b", length=28, parser_state=0x7f48ab7545d0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8001
      #19 0x000055bf61e48229 in dispatch_command (command=COM_QUERY, thd=0x7f4860000b00, packet=0x7f486000b271 "ALTER TABLE t1 DROP COLUMN b", packet_length=28, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1846
      #20 0x000055bf61e46c68 in do_command (thd=0x7f4860000b00) at /data/src/10.3/sql/sql_parse.cc:1391
      #21 0x000055bf61fa9aef in do_handle_one_connection (connect=0x55bf64f3b540) at /data/src/10.3/sql/sql_connect.cc:1402
      #22 0x000055bf61fa987c in handle_one_connection (arg=0x55bf64f3b540) at /data/src/10.3/sql/sql_connect.cc:1308
      #23 0x000055bf6242da8d in pfs_spawn_thread (arg=0x55bf64f43d70) at /data/src/10.3/storage/perfschema/pfs.cc:1862
      #24 0x00007f48b8177494 in start_thread (arg=0x7f48ab755700) at pthread_create.c:333
      #25 0x00007f48b655d93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      Not reproducible on 10.2.

      Initially this problem was interchangeable with MDEV-14906 (in the sense that they both were happening randomly on the same test cases), but MDEV-14906 has been presumably fixed now, and this one still happens.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              marko Marko Mäkelä
              Reporter:
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: