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

Assertion `index->lock.have_x() == has_index_lock' failed in row_log_apply_op

    XMLWordPrintable

    Details

      Description

      Filing separately from MDEV-26198 because this one seems to be a recent regression.

      The test case is non-deterministic, run with --repeat. It currently fails very well for me (usually on the 1st attempt or within a few), but it can vary on different machines and builds. Try to modify --sleep if it doesn't fail.

      --source include/have_innodb.inc
      --source include/have_sequence.inc
       
      CREATE TABLE t (pk INT PRIMARY KEY, f varchar(1024)) ENGINE=InnoDB;
      INSERT INTO t SELECT seq, REPEAT(CHR(seq%26+97),1024) FROM seq_1_to_10000;
       
      --connect (con1,localhost,root,,test)
      --send
        ALTER TABLE t ADD KEY (f);
       
      --connection default
      --sleep 0.2
      UPDATE t SET f = 'foo';
       
      --connection con1
      --reap
       
      # Cleanup
      DROP TABLE t;
      --disconnect con1
      

      10.6 a42e327a

      mariadbd: /data/src/10.6/storage/innobase/row/row0log.cc:3290: const mrec_t* row_log_apply_op(dict_index_t*, row_merge_dup_t*, dberr_t*, mem_heap_t*, mem_heap_t*, bool, const mrec_t*, const mrec_t*, rec_offs*): Assertion `index->lock.have_x() == has_index_lock' failed.
      220502  1:59:57 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f423bf82662 in __GI___assert_fail (assertion=0x5600cba65b58 "index->lock.have_x() == has_index_lock", file=0x5600cba63b28 "/data/src/10.6/storage/innobase/row/row0log.cc", line=3290, function=0x5600cba65d20 "const mrec_t* row_log_apply_op(dict_index_t*, row_merge_dup_t*, dberr_t*, mem_heap_t*, mem_heap_t*, bool, const mrec_t*, const mrec_t*, rec_offs*)") at assert.c:101
      #8  0x00005600cb305001 in row_log_apply_op (index=0x7f41dc021388, dup=0x7f42352ca590, error=0x7f42352ca35c, offsets_heap=0x7f41dc53ef78, heap=0x7f41dc070d18, has_index_lock=false, mrec=0x7f42343a6000 "b\003", mrec_end=0x7f42344a6000 'd' <repeats 200 times>..., offsets=0x7f41dc0201c8) at /data/src/10.6/storage/innobase/row/row0log.cc:3290
      #9  0x00005600cb307033 in row_log_apply_ops (trx=0x7f42365c4680, index=0x7f41dc021388, dup=0x7f42352ca590, stage=0x7f41dc020158) at /data/src/10.6/storage/innobase/row/row0log.cc:3632
      #10 0x00005600cb307766 in row_log_apply (trx=0x7f42365c4680, index=0x7f41dc021388, table=0x7f42352cb2f0, stage=0x7f41dc020158) at /data/src/10.6/storage/innobase/row/row0log.cc:3744
      #11 0x00005600cb181dfa in ha_innobase::commit_inplace_alter_table (this=0x7f41d821da70, altered_table=0x7f42352cb2f0, ha_alter_info=0x7f42352cb230, commit=true) at /data/src/10.6/storage/innobase/handler/handler0alter.cc:11036
      #12 0x00005600cad23670 in handler::ha_commit_inplace_alter_table (this=0x7f41d821da70, altered_table=0x7f42352cb2f0, ha_alter_info=0x7f42352cb230, commit=true) at /data/src/10.6/sql/handler.cc:5218
      #13 0x00005600caa856c2 in mysql_inplace_alter_table (thd=0x7f41dc000db8, table_list=0x7f41dc014238, table=0x7f41d8237f38, altered_table=0x7f42352cb2f0, ha_alter_info=0x7f42352cb230, target_mdl_request=0x7f42352cbb30, ddl_log_state=0x7f42352cb1d0, trigger_param=0x7f42352cb6e0, alter_ctx=0x7f42352cc690) at /data/src/10.6/sql/sql_table.cc:7471
      #14 0x00005600caa8e0d0 in mysql_alter_table (thd=0x7f41dc000db8, new_db=0x7f41dc0059b8, new_name=0x7f41dc005dd0, create_info=0x7f42352cd4a0, table_list=0x7f41dc014238, alter_info=0x7f42352cd3b0, order_num=0, order=0x0, ignore=false, if_exists=false) at /data/src/10.6/sql/sql_table.cc:10267
      #15 0x00005600cab41c92 in Sql_cmd_alter_table::execute (this=0x7f41dc0149f8, thd=0x7f41dc000db8) at /data/src/10.6/sql/sql_alter.cc:542
      #16 0x00005600ca98bd0a in mysql_execute_command (thd=0x7f41dc000db8, is_called_from_prepared_stmt=false) at /data/src/10.6/sql/sql_parse.cc:6012
      #17 0x00005600ca991d68 in mysql_parse (thd=0x7f41dc000db8, rawbuf=0x7f41dc014160 "ALTER TABLE t ADD KEY (f)", length=25, parser_state=0x7f42352ce500) at /data/src/10.6/sql/sql_parse.cc:8045
      #18 0x00005600ca97e3bb in dispatch_command (command=COM_QUERY, thd=0x7f41dc000db8, packet=0x7f41dc00b879 "", packet_length=25, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1912
      #19 0x00005600ca97cce8 in do_command (thd=0x7f41dc000db8, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1409
      #20 0x00005600cab36c5c in do_handle_one_connection (connect=0x5600ce6344c8, put_in_cache=true) at /data/src/10.6/sql/sql_connect.cc:1418
      #21 0x00005600cab368fb in handle_one_connection (arg=0x5600ce6344c8) at /data/src/10.6/sql/sql_connect.cc:1312
      #22 0x00005600cb051182 in pfs_spawn_thread (arg=0x5600ce6345a8) at /data/src/10.6/storage/perfschema/pfs.cc:2201
      #23 0x00007f423c44eea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #24 0x00007f423c04bdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      The failure most likely started happening on 10.6 after this commit:

      commit 4b80c11f52a3da189bafd7a772bcbf3519ceb41e
      Author: Thirunarayanan Balathandayuthapani
      Date:   Mon Apr 25 13:36:56 2022 +0530
       
          MDEV-15250  UPSERT during ALTER TABLE results in 'Duplicate entry' error for alter
          
          - InnoDB DDL results in `Duplicate entry' if concurrent DML throws
      

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              thiru Thirunarayanan Balathandayuthapani
              Reporter:
              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.