[MDEV-23235] Assertion `part_id == m_last_part' failed in ha_partition::delete_row Created: 2020-07-20  Updated: 2021-10-14  Resolved: 2021-10-14

Status: Closed
Project: MariaDB Server
Component/s: Backup, Partitioning, Virtual Columns
Affects Version/s: 10.4, 10.5
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Aleksey Midenkov
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates MDEV-20763 Table corruption or Assertion `btr_va... Closed
Relates
relates to MDEV-25532 Assertion `part_id == m_last_part' fa... Open

 Description    

--source include/have_innodb.inc
 
--source include/have_partition.inc
 
 
 
CREATE TABLE t1 (a CHAR(8) GENERATED ALWAYS AS ('') PERSISTENT) ENGINE=InnoDB PARTITION BY KEY(a) PARTITIONS 2;
 
SET SQL_MODE= 'EMPTY_STRING_IS_NULL';
 
INSERT INTO t1 () VALUES ();
 
 
 
BACKUP STAGE START;
 
BACKUP STAGE BLOCK_COMMIT;
 
 
 
--connect (con1,localhost,root,,test)
 
SET lock_wait_timeout= 1;
 
 
 
--error ER_LOCK_WAIT_TIMEOUT
 
DELETE FROM t1;
 
 
 
# Cleanup
 
--disconnect con1
 
--connection default
 
BACKUP STAGE END;
 
DROP TABLE t1;

10.4 956f21c3

 
mysqld: /data/src/10.4/sql/ha_partition.cc:4552: virtual int ha_partition::delete_row(const uchar*): Assertion `part_id == m_last_part' failed.
 
200720 19:22:20 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f1cd0a83f12 in __GI___assert_fail (assertion=0x557bbd9ac81a "part_id == m_last_part", file=0x557bbd9ab770 "/data/src/10.4/sql/ha_partition.cc", line=4552, function=0x557bbd9afc00 <ha_partition::delete_row(unsigned char const*)::__PRETTY_FUNCTION__> "virtual int ha_partition::delete_row(const uchar*)") at assert.c:101
 
#8  0x0000557bbd4a008b in ha_partition::delete_row (this=0x7f1c7c021248, buf=0x7f1c7c020e08 "\375        ", '\245' <repeats 23 times>, "\070\016\002|\034\177") at /data/src/10.4/sql/ha_partition.cc:4552
 
#9  0x0000557bbcc63752 in handler::ha_delete_row (this=0x7f1c7c021248, buf=0x7f1c7c020e08 "\375        ", '\245' <repeats 23 times>, "\070\016\002|\034\177") at /data/src/10.4/sql/handler.cc:6827
 
#10 0x0000557bbce1e59d in TABLE::delete_row (this=0x7f1c7c01ff80) at /data/src/10.4/sql/sql_delete.cc:289
 
#11 0x0000557bbce1b3da in mysql_delete (thd=0x7f1c7c000af0, table_list=0x7f1c7c011ea0, conds=0x0, order_list=0x7f1c7c0054a8, limit=18446744073709551615, options=0, result=0x0) at /data/src/10.4/sql/sql_delete.cc:804
 
#12 0x0000557bbc8fbcd6 in mysql_execute_command (thd=0x7f1c7c000af0) at /data/src/10.4/sql/sql_parse.cc:4719
 
#13 0x0000557bbc90682f in mysql_parse (thd=0x7f1c7c000af0, rawbuf=0x7f1c7c011dd8 "DELETE FROM t1", length=14, parser_state=0x7f1cc5db2570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7899
 
#14 0x0000557bbc8f2d64 in dispatch_command (command=COM_QUERY, thd=0x7f1c7c000af0, packet=0x7f1c7c0083a1 "DELETE FROM t1", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1834
 
#15 0x0000557bbc8f1506 in do_command (thd=0x7f1c7c000af0) at /data/src/10.4/sql/sql_parse.cc:1352
 
#16 0x0000557bbca7a5c4 in do_handle_one_connection (connect=0x557bbf2f8350) at /data/src/10.4/sql/sql_connect.cc:1412
 
#17 0x0000557bbca7a313 in handle_one_connection (arg=0x557bbf2f8350) at /data/src/10.4/sql/sql_connect.cc:1316
 
#18 0x0000557bbd479c93 in pfs_spawn_thread (arg=0x557bbf2970b0) at /data/src/10.4/storage/perfschema/pfs.cc:1869
 
#19 0x00007f1cd2a0c4a4 in start_thread (arg=0x7f1cc5db3700) at pthread_create.c:456
 
#20 0x00007f1cd0b40d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.4 and 10.5 debug builds.
No obvious problem on a non-debug build.
The test case is not applicable to earlier versions due to backup locks.

 Comments   
Comment by Aleksey Midenkov [ 2021-10-14 ]

Test case failure is hidden by MDEV-20763 fix.

Comment by Aleksey Midenkov [ 2021-10-14 ]

Reproduces for 10.4 ce141d07142

--source include/have_innodb.inc
 
--source include/have_partition.inc
 
 
 
create table t1 (a char(8) generated always as ('')) engine innodb
 
partition by key(a) partitions 2;
 
set sql_mode= 'EMPTY_STRING_IS_NULL';
 
insert into t1 () values ();
 
flush tables;
 
set sql_mode= default;
 
delete from t1;
 
# cleanup
 
drop tables t1;

Explanatory test case

--source include/have_innodb.inc
 
--source include/have_partition.inc
 
 
 
create table t1 (a char(8) generated always as ('')) engine innodb
 
partition by key(a) partitions 2;
 
set sql_mode= 'EMPTY_STRING_IS_NULL';
 
insert into t1 () values ();
 
select * from t1 partition (p0);
 
select * from t1 partition (p1);
 
 
 
set sql_mode= default;
 
flush tables;
 
select * from t1 partition (p0);
 
select * from t1 partition (p1);
 
insert into t1 () values ();
 
insert into t1 () values (NULL);
 
select * from t1 partition (p0);
 
select * from t1 partition (p1);
 
# cleanup
 
drop tables t1;

Result

set sql_mode= 'EMPTY_STRING_IS_NULL';
 
insert into t1 () values ();
 
select * from t1 partition (p0);
 
a
 
NULL
 
select * from t1 partition (p1);
 
a
 
set sql_mode= default;
 
flush tables;
 
select * from t1 partition (p0);
 
a
 
 
 
select * from t1 partition (p1);
 
a
 
insert into t1 () values ();
 
insert into t1 () values (NULL);
 
select * from t1 partition (p0);
 
a
 
 
 
select * from t1 partition (p1);
 
a

Comment by Aleksey Midenkov [ 2021-10-14 ]

Cause

While EMPTY_STRING_IS_NULL is active field is calculated as NULL and is inserted into p0 but as original value (empty string). SELECT displays NULL as long as EMPTY_STRING_IS_NULL is on but displays empty string otherwise. When EMPTY_STRING_IS_NULL is off INSERT writes into p1 and therefore empty strings are expected there. The assertion happened because empty string is found in p0 and EMPTY_STRING_IS_NULL is inactive.

The fix for MDEV-20763 fixes this as well.

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