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

Assertion `thd->m_transaction_psi == __null' fails upon replicating online ALTER

    XMLWordPrintable

Details

    Description

      Run the test case with --mysqld=--slave_exec_mode=IDEMPOTENT. On some reason setting it dynamically doesn't have the same effect.

      --source include/have_debug_sync.inc
      --source include/master-slave.inc
       
      --connection master
      CREATE TABLE t (a char(8)) ENGINE=MyISAM;
      INSERT INTO t VALUES ('foo'),('bar');
       
      --connection master1
      --send SET debug_sync= 'now wait_for go_dml'
       
      --connection master
      SET debug_sync= 'alter_table_online_progress signal go_dml wait_for go_alter';
      --send ALTER TABLE t FORCE
       
      --connection master1
      --reap
      INSERT INTO t (a) VALUES ('qux');
      SET debug_sync= 'now signal go_alter';
       
      --connection master
      --reap
      --sync_slave_with_master
       
      # Cleanup
      --connection master
      DROP TABLE t;
      SET debug_sync= reset;
      --source include/rpl_end.inc
      

      bb-11.2-oalter d53f4581

      mariadbd: /data/src/bb-11.2-oalter-asan/sql/transaction.cc:336: bool trans_commit_implicit(THD*): Assertion `thd->m_transaction_psi == __null' failed.
      230731 14:18:08 [ERROR] mysqld got signal 6 ;
       
      #9  0x00007f834a453df2 in __GI___assert_fail (assertion=0x55f670a7fee0 "thd->m_transaction_psi == __null", file=0x55f670a7f7e0 "/data/src/bb-11.2-oalter-asan/sql/transaction.cc", line=336, function=0x55f670a7ff40 "bool trans_commit_implicit(THD*)") at ./assert/assert.c:101
      #10 0x000055f66e22ad75 in trans_commit_implicit (thd=0x62c000260218) at /data/src/bb-11.2-oalter-asan/sql/transaction.cc:336
      #11 0x000055f66e81f3ae in ha_enable_transaction (thd=0x62c000260218, on=true) at /data/src/bb-11.2-oalter-asan/sql/handler.cc:5784
      #12 0x000055f66dfca324 in mysql_trans_commit_alter_copy_data (thd=0x62c000260218) at /data/src/bb-11.2-oalter-asan/sql/sql_table.cc:11660
      #13 0x000055f66dfd1379 in copy_data_between_tables (thd=0x62c000260218, from=0x619000123498, to=0x619000128e98, create=..., ignore=false, order_num=0, order=0x0, copied=0x7f833a1bd4c0, deleted=0x7f833a1bd4e0, keys_onoff=Alter_info::LEAVE_AS_IS, alter_ctx=0x7f833a1bf460, online=true, start_alter_id=0) at /data/src/bb-11.2-oalter-asan/sql/sql_table.cc:12218
      #14 0x000055f66dfc40e7 in mysql_alter_table (thd=0x62c000260218, new_db=0x62c000265000, new_name=0x62c000265450, create_info=0x7f833a1c03c0, table_list=0x62900027b2c0, recreate_info=0x7f833a1c0230, alter_info=0x7f833a1c0290, order_num=0, order=0x0, ignore=false, if_exists=false) at /data/src/bb-11.2-oalter-asan/sql/sql_table.cc:11180
      #15 0x000055f66e1f7881 in Sql_cmd_alter_table::execute (this=0x62900027b9e8, thd=0x62c000260218) at /data/src/bb-11.2-oalter-asan/sql/sql_alter.cc:571
      #16 0x000055f66dbfb5c0 in mysql_execute_command (thd=0x62c000260218, is_called_from_prepared_stmt=false) at /data/src/bb-11.2-oalter-asan/sql/sql_parse.cc:5764
      #17 0x000055f66dc0c712 in mysql_parse (thd=0x62c000260218, rawbuf=0x60e0000a0883 "ALTER TABLE t FORCE", length=19, parser_state=0x7f833a1c1950) at /data/src/bb-11.2-oalter-asan/sql/sql_parse.cc:7798
      #18 0x000055f66ecf27d2 in Query_log_event::do_apply_event (this=0x613000110958, rgi=0x61d00034f880, query_arg=0x60e0000a0883 "ALTER TABLE t FORCE", q_len_arg=19) at /data/src/bb-11.2-oalter-asan/sql/log_event_server.cc:2145
      #19 0x000055f66ecec23f in Query_log_event::do_apply_event (this=0x613000110958, rgi=0x61d00034f880) at /data/src/bb-11.2-oalter-asan/sql/log_event_server.cc:1582
      #20 0x000055f66ecccd09 in Log_event::apply_event (this=0x613000110958, rgi=0x61d00034f880) at /data/src/bb-11.2-oalter-asan/sql/log_event.cc:3880
      #21 0x000055f66d8ae355 in apply_event_and_update_pos_apply (ev=0x613000110958, thd=0x62c000260218, rgi=0x61d00034f880, reason=0) at /data/src/bb-11.2-oalter-asan/sql/slave.cc:3877
      #22 0x000055f66d8aeeb6 in apply_event_and_update_pos (ev=0x613000110958, thd=0x62c000260218, rgi=0x61d00034f880) at /data/src/bb-11.2-oalter-asan/sql/slave.cc:4043
      #23 0x000055f66d8b1afd in exec_relay_log_event (thd=0x62c000260218, rli=0x62a0000202c0, serial_rgi=0x61d00034f880) at /data/src/bb-11.2-oalter-asan/sql/slave.cc:4440
      #24 0x000055f66d8bd702 in handle_slave_sql (arg=0x62a00001e200) at /data/src/bb-11.2-oalter-asan/sql/slave.cc:5626
      #25 0x000055f66f134e63 in pfs_spawn_thread (arg=0x61700004a318) at /data/src/bb-11.2-oalter-asan/storage/perfschema/pfs.cc:2201
      #26 0x00007f834a4a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
      #27 0x00007f834a5285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
      

      Note that there is no conflict in this scenario, so IDEMPOTENT mode shouldn't make any difference for the outcome at all (in addition to that naturally it shouldn't crash).

      I tentatively attribute the failure to MDEV-16329 because I could only reproduce it on bb-11.2-oalter branch.
      Since the test case above uses an online-alter-specific debug sync point, it is not directly applicable to the baseline. I tried to use its non-deterministic counterpart, involving race condition between INSERT and ALTER, and while it fails fairly quickly on bb-11.2-oalter, it never failed for me on the baseline. However, it is not 100% guarantee.

      Attachments

        Issue Links

          Activity

            People

              nikitamalyavin Nikita Malyavin
              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.