[MDEV-21819] #2 Assertion `inited == NONE || update_handler != this' failed in handler::ha_write_row Created: 2020-02-25  Updated: 2023-04-19  Resolved: 2023-04-19

Status: Closed
Project: MariaDB Server
Component/s: Partitioning, Server, Versioned Tables
Fix Version/s: 10.5.2

Type: Task Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None


 Description   

Note: It's different from MDEV-21627 which is already fixed and the test case from it doesn't cause a failure

--source include/have_partition.inc
 
CREATE TABLE t1 (a INT, b BLOB, s DATE, e DATE, PERIOD FOR app(s,e), UNIQUE(b)) ENGINE=MyISAM PARTITION BY HASH(a) PARTITIONS 2;
INSERT INTO t1 VALUES (1,'foo','2022-01-01', '2025-01-01');
--error ER_DUP_ENTRY
DELETE FROM t1 FOR PORTION OF app FROM '2023-01-01' TO '2024-01-01';
 
# Cleanup
DROP TABLE t1;

bb-10.5-monty c13d415e

mysqld: /data/src/bb-10.5-monty/sql/handler.cc:6713: int handler::ha_write_row(const uchar*): Assertion `inited == NONE || update_handler != this' failed.
200225 22:08:30 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f61d0a86f12 in __GI___assert_fail (assertion=0x55c5280a8430 "inited == NONE || update_handler != this", file=0x55c5280a5f68 "/data/src/bb-10.5-monty/sql/handler.cc", line=6713, function=0x55c5280aa940 <handler::ha_write_row(unsigned char const*)::__PRETTY_FUNCTION__> "int handler::ha_write_row(const uchar*)") at assert.c:101
#8  0x000055c5274fde07 in handler::ha_write_row (this=0x7f619018b888, buf=0x7f6190009f78 "\370\001") at /data/src/bb-10.5-monty/sql/handler.cc:6713
#9  0x000055c5278498bb in ha_partition::write_row (this=0x7f619018a808, buf=0x7f6190009f78 "\370\001") at /data/src/bb-10.5-monty/sql/ha_partition.cc:4344
#10 0x000055c5274fdf3e in handler::ha_write_row (this=0x7f619018a808, buf=0x7f6190009f78 "\370\001") at /data/src/bb-10.5-monty/sql/handler.cc:6717
#11 0x000055c5272ef284 in TABLE::period_make_insert (this=0x7f61901a0400, src=0x7f6190013cc0, dst=0x7f619018c068) at /data/src/bb-10.5-monty/sql/table.cc:8566
#12 0x000055c5272ef42b in TABLE::insert_portion_of_time (this=0x7f61901a0400, thd=0x7f6190000b00, period_conds=..., rows_inserted=0x7f61c5e13590) at /data/src/bb-10.5-monty/sql/table.cc:8589
#13 0x000055c5276c18da in mysql_delete (thd=0x7f6190000b00, table_list=0x7f61900135e0, conds=0x7f6190014a90, order_list=0x7f61900054d8, limit=18446744073709551615, options=0, result=0x0) at /data/src/bb-10.5-monty/sql/sql_delete.cc:798
#14 0x000055c5271a679d in mysql_execute_command (thd=0x7f6190000b00) at /data/src/bb-10.5-monty/sql/sql_parse.cc:4740
#15 0x000055c5271b15be in mysql_parse (thd=0x7f6190000b00, rawbuf=0x7f61900134a8 "DELETE FROM t1 FOR PORTION OF app FROM '2023-01-01' TO '2024-01-01'", length=67, parser_state=0x7f61c5e14570, is_com_multi=false, is_next_command=false) at /data/src/bb-10.5-monty/sql/sql_parse.cc:7925
#16 0x000055c52719d19b in dispatch_command (command=COM_QUERY, thd=0x7f6190000b00, packet=0x7f6190158271 "DELETE FROM t1 FOR PORTION OF app FROM '2023-01-01' TO '2024-01-01'", packet_length=67, is_com_multi=false, is_next_command=false) at /data/src/bb-10.5-monty/sql/sql_parse.cc:1845
#17 0x000055c52719b8e2 in do_command (thd=0x7f6190000b00) at /data/src/bb-10.5-monty/sql/sql_parse.cc:1364
#18 0x000055c52733d63d in do_handle_one_connection (connect=0x55c529bd0280, put_in_cache=true) at /data/src/bb-10.5-monty/sql/sql_connect.cc:1422
#19 0x000055c52733d36c in handle_one_connection (arg=0x55c529bd0280) at /data/src/bb-10.5-monty/sql/sql_connect.cc:1319
#20 0x000055c52789a9cb in pfs_spawn_thread (arg=0x55c529b3a390) at /data/src/bb-10.5-monty/storage/perfschema/pfs.cc:1869
#21 0x00007f61d2a0f4a4 in start_thread (arg=0x7f61c5e15700) at pthread_create.c:456
#22 0x00007f61d0b43d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97



 Comments   
Comment by Michael Widenius [ 2020-02-26 ]

Problem was that long unique was not properly handled for partitioned tables.
unique was checked twice, first for partitioned table and then for the underlying table.
My fix fixed the first properly but I missed the second test that should never happen.
Have now removed the second unique check, which fixes this issue

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