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

Assertion `cmp_rec_rec(rec, old_rec, offsets, old_offsets, m_index) > 0' failed in PageBulk::insert or unexpected auto-increment value

Details

    Description

      --source include/have_innodb.inc
      --source include/have_sequence.inc
       
      CREATE TABLE t1 (a INT NOT NULL, UNIQUE KEY (a)) ENGINE=InnoDB;
      INSERT INTO t1 SELECT seq FROM seq_1_to_128;
      ALTER TABLE t1 ADD b TINYINT NOT NULL AUTO_INCREMENT PRIMARY KEY;
       
      # Cleanup
      DROP TABLE t1;
      

      10.4 debug a17a327f

      mysqld: /data/src/10.4/storage/innobase/btr/btr0bulk.cc:195: void PageBulk::insert(const rec_t*, offset_t*): Assertion `cmp_rec_rec(rec, old_rec, offsets, old_offsets, m_index) > 0' failed.
      200227 18:45:15 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f48b6bb5f12 in __GI___assert_fail (assertion=0x55d3e8c20770 "cmp_rec_rec(rec, old_rec, offsets, old_offsets, m_index) > 0", file=0x55d3e8c206c0 "/data/src/10.4/storage/innobase/btr/btr0bulk.cc", line=195, function=0x55d3e8c215a0 <PageBulk::insert(unsigned char const*, unsigned short*)::__PRETTY_FUNCTION__> "void PageBulk::insert(const rec_t*, offset_t*)") at assert.c:101
      #8  0x000055d3e849446b in PageBulk::insert (this=0x7f486007c8e0, rec=0x7f486007fc0d "", offsets=0x7f486007fc20) at /data/src/10.4/storage/innobase/btr/btr0bulk.cc:195
      #9  0x000055d3e8496a5c in BtrBulk::insert (this=0x7f48600a07d0, tuple=0x7f48605d8370, level=0) at /data/src/10.4/storage/innobase/btr/btr0bulk.cc:939
      #10 0x000055d3e83457a2 in BtrBulk::insert (this=0x7f48600a07d0, tuple=0x7f48605d8370) at /data/src/10.4/storage/innobase/include/btr0bulk.h:310
      #11 0x000055d3e837cd68 in row_merge_insert_index_tuples (index=0x7f4860074a30, old_table=0x7f486000ba10, fd=..., block=0x0, row_buf=0x7f4860074140, btr_bulk=0x7f48600a07d0, table_total_rows=128, pct_progress=0, pct_cost=33.333333333333336, crypt_block=0x0, space=6, stage=0x0) at /data/src/10.4/storage/innobase/row/row0merge.cc:3669
      #12 0x000055d3e83791b9 in row_merge_read_clustered_index (trx=0x7f48b09f7140, table=0x7f48b015a800, old_table=0x7f486000ba10, new_table=0x7f4860070b90, online=false, index=0x7f48600704f8, fts_sort_idx=0x0, psort_info=0x0, files=0x7f486009a5c0, key_numbers=0x7f4860070508, n_index=2, defaults=0x7f4860070568, add_v=0x0, col_map=0x7f4860070628, add_autoinc=1, sequence=..., block=0x7f489c4f9000 <error: Cannot access memory at address 0x7f489c4f9000>, skip_pk_sort=true, tmpfd=0x7f48b0159910, stage=0x7f4860074e70, pct_cost=33.333333333333336, crypt_block=0x0, eval_table=0x7f48b015a800, allow_not_null=false) at /data/src/10.4/storage/innobase/row/row0merge.cc:2519
      #13 0x000055d3e8380112 in row_merge_build_indexes (trx=0x7f48b09f7140, old_table=0x7f486000ba10, new_table=0x7f4860070b90, online=false, indexes=0x7f48600704f8, key_numbers=0x7f4860070508, n_indexes=2, table=0x7f48b015a800, defaults=0x7f4860070568, col_map=0x7f4860070628, add_autoinc=1, sequence=..., skip_pk_sort=true, stage=0x7f4860074e70, add_v=0x0, eval_table=0x7f48b015a800, allow_not_null=false) at /data/src/10.4/storage/innobase/row/row0merge.cc:4709
      #14 0x000055d3e8231c62 in ha_innobase::inplace_alter_table (this=0x7f48601a0328, altered_table=0x7f48b015a800, ha_alter_info=0x7f48b015a770) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:8370
      #15 0x000055d3e7d30fe9 in handler::ha_inplace_alter_table (this=0x7f48601a0328, altered_table=0x7f48b015a800, ha_alter_info=0x7f48b015a770) at /data/src/10.4/sql/handler.h:4368
      #16 0x000055d3e7d2507a in mysql_inplace_alter_table (thd=0x7f4860000af0, table_list=0x7f48600132c8, table=0x7f486019ca80, altered_table=0x7f48b015a800, ha_alter_info=0x7f48b015a770, inplace_supported=HA_ALTER_INPLACE_COPY_LOCK, target_mdl_request=0x7f48b015b5d0, alter_ctx=0x7f48b015c100) at /data/src/10.4/sql/sql_table.cc:7717
      #17 0x000055d3e7d2bf3c in mysql_alter_table (thd=0x7f4860000af0, new_db=0x7f48600052b0, new_name=0x7f48600056b8, create_info=0x7f48b015ccf0, table_list=0x7f48600132c8, alter_info=0x7f48b015cc30, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10111
      #18 0x000055d3e7dc4033 in Sql_cmd_alter_table::execute (this=0x7f4860013b70, thd=0x7f4860000af0) at /data/src/10.4/sql/sql_alter.cc:508
      #19 0x000055d3e7c427a5 in mysql_execute_command (thd=0x7f4860000af0) at /data/src/10.4/sql/sql_parse.cc:6101
      #20 0x000055d3e7c47e67 in mysql_parse (thd=0x7f4860000af0, rawbuf=0x7f4860013198 "ALTER TABLE t1 ADD b TINYINT NOT NULL AUTO_INCREMENT PRIMARY KEY", length=64, parser_state=0x7f48b015e160, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7900
      #21 0x000055d3e7c3304a in dispatch_command (command=COM_QUERY, thd=0x7f4860000af0, packet=0x7f48601371f1 "ALTER TABLE t1 ADD b TINYINT NOT NULL AUTO_INCREMENT PRIMARY KEY", packet_length=64, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
      #22 0x000055d3e7c316d7 in do_command (thd=0x7f4860000af0) at /data/src/10.4/sql/sql_parse.cc:1360
      #23 0x000055d3e7dba943 in do_handle_one_connection (connect=0x55d3ea767060) at /data/src/10.4/sql/sql_connect.cc:1412
      #24 0x000055d3e7dba692 in handle_one_connection (arg=0x55d3ea767060) at /data/src/10.4/sql/sql_connect.cc:1316
      #25 0x000055d3e87c1585 in pfs_spawn_thread (arg=0x55d3ea6d1670) at /data/src/10.4/storage/perfschema/pfs.cc:1869
      #26 0x00007f48b8b3e4a4 in start_thread (arg=0x7f48b015f700) at pthread_create.c:456
      #27 0x00007f48b6c72d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
      

      Reproducible with 10.2-10.5.

      Non-debug build doesn't crash, but the behavior is questionable: INSERT works without errors or warnings, for the last row auto-increment rotates and -128 is inserted.
      This part is reproducible with 10.1 as well.
      MySQL 5.6/5.7 throws an error.

      Attachments

        Activity

          The assertion is valid and necessary. It tries to ensure that index entries are already sorted when they are being added to the index page.

          marko Marko Mäkelä added a comment - The assertion is valid and necessary. It tries to ensure that index entries are already sorted when they are being added to the index page.

          I can repeat this with 10.2 1e31d74833d56609f8711022394c1eb2eb25a19a with

          ./mtr --rr
          

          Thus, an rr replay trace can be considered to exist.

          marko Marko Mäkelä added a comment - I can repeat this with 10.2 1e31d74833d56609f8711022394c1eb2eb25a19a with ./mtr --rr Thus, an rr replay trace can be considered to exist.

          The function innobase_pk_order_preserved() was wrongly returning true. It would correctly return true if we were adding an existing column before columns that existed in the old definition of the PRIMARY KEY. But, in this case we are adding a new column, and the assumption is that a newly added column in native ALTER TABLE must contain a constant value for all rows of the table.

          The only cases how a non-constant column can be added via the native interface are GENERATED columns and AUTO_INCREMENT. We do not support PRIMARY KEY on a generated column (neither virtual or stored, and currently we do not support adding generated stored columns natively).

          Our only omission should be the AUTO_INCREMENT case. We must treat it in the same way as adding an existing column of the table to the middle of the PRIMARY KEY, such as this case in innodb.innodb-index:

          --echo # Must sort
          --echo # Change PK(f1,f12) to (f1,existing_columns)
          --enable_info
          alter table t1 drop primary key, add primary key(f1,f3);
          --disable_info
          eval $innodb_metrics_select;
          SET GLOBAL innodb_monitor_reset = module_ddl;
          

          marko Marko Mäkelä added a comment - The function innobase_pk_order_preserved() was wrongly returning true . It would correctly return true if we were adding an existing column before columns that existed in the old definition of the PRIMARY KEY . But, in this case we are adding a new column, and the assumption is that a newly added column in native ALTER TABLE must contain a constant value for all rows of the table. The only cases how a non-constant column can be added via the native interface are GENERATED columns and AUTO_INCREMENT . We do not support PRIMARY KEY on a generated column (neither virtual or stored, and currently we do not support adding generated stored columns natively). Our only omission should be the AUTO_INCREMENT case. We must treat it in the same way as adding an existing column of the table to the middle of the PRIMARY KEY , such as this case in innodb.innodb-index : --echo # Must sort --echo # Change PK(f1,f12) to (f1,existing_columns) --enable_info alter table t1 drop primary key , add primary key (f1,f3); --disable_info eval $innodb_metrics_select; SET GLOBAL innodb_monitor_reset = module_ddl;

          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.