[MDEV-22218] InnoDB: Failing assertion: node->pcur->rel_pos == BTR_PCUR_ON upon LOAD DATA with NO_BACKSLASH_ESCAPES in SQL_MODE and unique blob in table Created: 2020-04-11  Updated: 2020-04-13  Resolved: 2020-04-13

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.5
Fix Version/s: 10.5.3

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: regression


 Description   

--source include/have_innodb.inc
 
SET SQL_MODE= CONCAT(@@sql_mode,',NO_BACKSLASH_ESCAPES');
CREATE TABLE t1 (pk INT PRIMARY KEY, f BLOB, UNIQUE(f)) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1, NULL);
SELECT * INTO OUTFILE 't1.data' FROM t1;
LOAD DATA INFILE 't1.data' REPLACE INTO TABLE t1;
 
# Cleanup
--let $datadir= `SELECT @@datadir`
--remove_file $datadir/test/t1.data
DROP TABLE t1;

10.5 6bbc0eed

2020-04-11 03:19:56 0x7fba35138300  InnoDB: Assertion failure in file /data/src/10.5/storage/innobase/row/row0mysql.cc line 1854
InnoDB: Failing assertion: node->pcur->rel_pos == BTR_PCUR_ON
 
#6  0x00005614b0ab4cbb in ut_dbg_assertion_failed (expr=0x5614b1dfebe0 "node->pcur->rel_pos == BTR_PCUR_ON", file=0x5614b1dfc820 "/data/src/10.5/storage/innobase/row/row0mysql.cc", line=1854) at /data/src/10.5/storage/innobase/ut/ut0dbg.cc:60
#7  0x00005614b08ea21e in row_update_for_mysql (prebuilt=0x62000003d120) at /data/src/10.5/storage/innobase/row/row0mysql.cc:1854
#8  0x00005614b056a6e9 in ha_innobase::update_row (this=0x61d000247d28, old_row=0x6190000df350 "\277\001", new_row=0x6190000df338 "\374\001") at /data/src/10.5/storage/innobase/handler/ha_innodb.cc:8568
#9  0x00005614afaba8e9 in handler::ha_update_row (this=0x61d000247d28, old_data=0x6190000df350 "\277\001", new_data=0x6190000df338 "\374\001") at /data/src/10.5/sql/handler.cc:7000
#10 0x00005614af20eb38 in write_record (thd=0x62b00007e288, table=0x62000003c108, info=0x7fba35135110, sink=0x0) at /data/src/10.5/sql/sql_insert.cc:2010
#11 0x00005614af2a2e4b in read_sep_field (thd=0x62b00007e288, info=..., table_list=0x62b000085450, fields_vars=..., set_fields=..., set_values=..., read_info=..., enclosed=..., skip_lines=0, ignore_check_option_errors=false) at /data/src/10.5/sql/sql_load.cc:1170
#12 0x00005614af29f1ed in mysql_load (thd=0x62b00007e288, ex=0x62b0000853a8, table_list=0x62b000085450, fields_vars=..., set_fields=..., set_values=..., handle_duplicates=DUP_REPLACE, ignore=false, read_file_from_client=false) at /data/src/10.5/sql/sql_load.cc:675
#13 0x00005614af2cec28 in mysql_execute_command (thd=0x62b00007e288) at /data/src/10.5/sql/sql_parse.cc:4963
#14 0x00005614af2e3125 in mysql_parse (thd=0x62b00007e288, rawbuf=0x62b0000852a8 "LOAD DATA INFILE 't1.data' REPLACE INTO TABLE t1", length=48, parser_state=0x7fba35136a50, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7953
#15 0x00005614af2b8f15 in dispatch_command (command=COM_QUERY, thd=0x62b00007e288, packet=0x6290002b2289 "LOAD DATA INFILE 't1.data' REPLACE INTO TABLE t1", packet_length=48, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1839
#16 0x00005614af2b594a in do_command (thd=0x62b00007e288) at /data/src/10.5/sql/sql_parse.cc:1358
#17 0x00005614af6d4bc3 in do_handle_one_connection (connect=0x61100003b808, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1422
#18 0x00005614af6d445e in handle_one_connection (arg=0x61100003b6c8) at /data/src/10.5/sql/sql_connect.cc:1319
#19 0x00005614b03735d8 in pfs_spawn_thread (arg=0x61600000f708) at /data/src/10.5/storage/perfschema/pfs.cc:2201
#20 0x00007fba437adfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#21 0x00007fba42ffc4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Debug and non-debug builds fail the same way.
Not reproducible on 10.4.

The failure appeared in 10.5 tree with this commit:

commit 0515577d128318e1b62511846d88d0c56226168d (HEAD)
Author: Sergei Golubchik <serg@mariadb.org>
Date:   Thu Mar 5 19:19:57 2020 +0100
 
    cleanup: prepare "update_handler" for WITHOUT OVERLAPS


Generated at Thu Feb 08 09:13:05 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.