Matthias Leich added a comment - 2019-03-12 15:29 Variation of the problem (assert at different place) --------------------------------------------------------------------------------   --source include/have_innodb.inc --disable_abort_on_error   SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION' ; CREATE TABLE t1 ( pk INTEGER AUTO_INCREMENT , col1 INTEGER , col2 INTEGER , PRIMARY KEY (pk) ) ENGINE=InnoDB ; INSERT INTO t1 (col2 , col1) VALUES ( 7, 1) ; ALTER IGNORE TABLE `t1` ADD IF NOT EXISTS ( `col1` SERIAL ) ; ALTER IGNORE TABLE `t1` MODIFY `col1` VARCHAR(15129) ; ALTER TABLE `t1` ADD SYSTEM VERSIONING ; SELECT * FROM `t1` INTO OUTFILE 'load_t1' ; LOAD DATA INFILE 'load_t1' REPLACE INTO TABLE t1 ; LOAD DATA INFILE 'load_t1' REPLACE INTO TABLE t1 ; --enable_abort_on_error DROP TABLE t1;   On 10.4 I get: Version: '10.4.4-MariaDB-debug-log' socket: 'bld_debug/mysql-test/var/tmp/mysqld.1.sock' port: 16000 Source distribution 2019-03-12 16:23:47 0x7fd8b97e4700 InnoDB: Assertion failure in file storage/innobase/row/row0ins.cc line 267 InnoDB: Failing assertion: !cursor->index->is_committed() ... Query (0x7fd868014730): LOAD DATA INFILE 'load_t1' REPLACE INTO TABLE t1 Connection ID (thread ID): 9 Status: NOT_KILLED ... #3 <signal handler called> #4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #5 0x00007fd8c04c7f5d in __GI_abort () at abort.c:90 #6 0x00005599ed1b51f3 in ut_dbg_assertion_failed (expr=0x5599ed89cbe8 "!cursor->index->is_committed()", file=0x5599ed89caa0 "storage/innobase/row/row0ins.cc", line=267) at storage/innobase/ut/ut0dbg.cc:60 #7 0x00005599ed0cc3ba in row_ins_sec_index_entry_by_modify (flags=0, mode=2, cursor=0x7fd8b97dfd20, offsets=0x7fd8b97dfcc0, offsets_heap=0x7fd868138910, heap=0x7fd86806e430, entry=0x7fd86807cb08, thr=0x7fd8681b3788, mtr=0x7fd8b97e00e0) at storage/innobase/row/row0ins.cc:267 #8 0x00005599ed0d3e96 in row_ins_sec_index_entry_low (flags=0, mode=2, index=0x7fd8681311e8, offsets_heap=0x7fd868138910, heap=0x7fd86806e430, entry=0x7fd86807cb08, trx_id=0, thr=0x7fd8681b3788, dup_chk_only=false) at storage/innobase/row/row0ins.cc:3140 #9 0x00005599ed0d489b in row_ins_sec_index_entry (index=0x7fd8681311e8, entry=0x7fd86807cb08, thr=0x7fd8681b3788, dup_chk_only=false) at storage/innobase/row/row0ins.cc:3359 #10 0x00005599ed146775 in row_upd_sec_index_entry (node=0x7fd8681b33c0, thr=0x7fd8681b3788) at storage/innobase/row/row0upd.cc:2516 #11 0x00005599ed146960 in row_upd_sec_step (node=0x7fd8681b33c0, thr=0x7fd8681b3788) at storage/innobase/row/row0upd.cc:2543 #12 0x00005599ed1493ca in row_upd (node=0x7fd8681b33c0, thr=0x7fd8681b3788) at storage/innobase/row/row0upd.cc:3322 #13 0x00005599ed149731 in row_upd_step (thr=0x7fd8681b3788) at storage/innobase/row/row0upd.cc:3437 #14 0x00005599ed0f7197 in row_update_for_mysql (prebuilt=0x7fd86807f258) at storage/innobase/row/row0mysql.cc:1890 #15 0x00005599ecf8fcf0 in ha_innobase::update_row (this=0x7fd86807eaa0, old_row=0x7fd868074420 "\240\001", new_row=0x7fd8680708e0 "\370\001") at storage/innobase/handler/ha_innodb.cc:8895 #16 0x00005599ecd6ff09 in handler::ha_update_row (this=0x7fd86807eaa0, old_data=0x7fd868074420 "\240\001", new_data=0x7fd8680708e0 "\370\001") at sql/handler.cc:6747 #17 0x00005599ec9d42ec in write_record (thd=0x7fd868000ce8, table=0x7fd86807dca8, info=0x7fd8b97e2000) at sql/sql_insert.cc:1941 #18 0x00005599eca09d58 in read_sep_field (thd=0x7fd868000ce8, info=..., table_list=0x7fd868014898, fields_vars=..., set_fields=..., set_values=..., read_info=..., enclosed=..., skip_lines=0, ignore_check_option_errors=false) at sql/sql_load.cc:1157 #19 0x00005599eca08385 in mysql_load (thd=0x7fd868000ce8, ex=0x7fd868014810, table_list=0x7fd868014898, fields_vars=..., set_fields=..., set_values=..., handle_duplicates=DUP_REPLACE, ignore=false, read_file_from_client=false) at sql/sql_load.cc:665 #20 0x00005599eca1f3f2 in mysql_execute_command (thd=0x7fd868000ce8) at sql/sql_parse.cc:5230 #21 0x00005599eca2988f in mysql_parse (thd=0x7fd868000ce8, rawbuf=0x7fd868014730 "LOAD DATA INFILE 'load_t1' REPLACE INTO TABLE t1", length=48, parser_state=0x7fd8b97e3170, is_com_multi=false, is_next_command=false) at sql/sql_parse.cc:8204 #22 0x00005599eca14ba0 in dispatch_command (command=COM_QUERY, thd=0x7fd868000ce8, packet=0x7fd86800a189 "LOAD DATA INFILE 'load_t1' REPLACE INTO TABLE t1 ", packet_length=49, is_com_multi=false, is_next_command=false) at sql/sql_parse.cc:1828 #23 0x00005599eca1335f in do_command (thd=0x7fd868000ce8) at sql/sql_parse.cc:1357 #24 0x00005599ecb8bceb in do_handle_one_connection (connect=0x5599ef9a6548) at sql/sql_connect.cc:1399 #25 0x00005599ecb8ba4f in handle_one_connection (arg=0x5599ef9a6548) at sql/sql_connect.cc:1302 #26 0x00005599ed4c09aa in pfs_spawn_thread (arg=0x5599ef9dd0d8) at storage/perfschema/pfs.cc:1862 #27 0x00007fd8c136d7fc in start_thread (arg=0x7fd8b97e4700) at pthread_create.c:465 #28 0x00007fd8c05a3b5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95  

Marko Mäkelä added a comment - 2019-03-13 08:06 - edited I believe that this is one more 10.4.3 regression due to MDEV-371 . I cannot reproduce any crash on 10.2 or 10.3. In 10.4, the check fails for the index col1 , whose fields internally are DB_ROW_HASH_1 and DB_ROW_ID . Here is a simplified test with some commentary: --source include/have_innodb.inc   # with VARCHAR (79), all results are correct CREATE TABLE t1 (a VARCHAR (7961)) ENGINE=InnoDB;   INSERT INTO t1 VALUES ( 'f' ), ( 'o' ), ( 'o' ); SELECT * FROM t1 INTO OUTFILE 'load.data' ;   ALTER IGNORE TABLE t1 ADD UNIQUE INDEX (a); # returns 2 rows with a= NULL , instead of rows ( 'f' ),( 'o' )! SELECT * FROM t1; ALTER TABLE t1 ADD SYSTEM VERSIONING ; # returns empty table instead of a table with the 2 rows ! SELECT * FROM t1; REPLACE INTO t1 VALUES ( 'f' ), ( 'o' ), ( 'o' ); # still returns an empty table instead of rows ( 'f' ),( 'o' )! SELECT * FROM t1; # This should be equivalent to the REPLACE above, but is not ! LOAD DATA INFILE 'load.data' REPLACE INTO TABLE t1; DROP TABLE t1; --let $datadir= `select @@datadir` --remove_file $datadir/test/load.data Without the ADD SYSTEM VERSIONING , the LOAD DATA INFILE would not crash, and the 2 last SELECT would return 2 records of a=NULL (instead of returning the 2 records with the correct data).

Sachin Setiya (Inactive) added a comment - 2019-03-19 11:11 bb-10.4-sachin