[MDEV-24522] Assertion `inited==NONE' fails upon UPDATE on versioned table with unique blob Created: 2021-01-04  Updated: 2021-01-30  Resolved: 2021-01-30

Status: Closed
Project: MariaDB Server
Component/s: Server, Versioned Tables
Affects Version/s: 10.4
Fix Version/s: 10.4.18, 10.5.9

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: regression, unique-blobs

Issue Links:
Problem/Incident
is caused by MDEV-23446 UPDATE does not insert history row if... Closed
Relates
relates to MDEV-371 Unique indexes for blobs Closed

 Description   

CREATE TABLE t1 (a INT, b INT, c TEXT, UNIQUE(c), KEY (b)) ENGINE=MyISAM WITH SYSTEM VERSIONING;
INSERT INTO t1 VALUES (1,10,'foo'),(2,11,'bar');
 
UPDATE t1 SET a = 3 WHERE b <= 10;
UPDATE t1 SET a = 3 WHERE b <= 10;
 
# Cleanup
DROP TABLE t1;

10.4 d67e17bb

#3  <signal handler called>
#4  0x000055c0fa3d6be7 in DsMrr_impl::dsmrr_next (this=0x7faa9007d1e0, range_info=0x7faaa261b708) at /data/src/10.4/sql/multi_range_read.cc:1491
#5  0x000055c0fa5f1a3b in QUICK_RANGE_SELECT::get_next (this=0x7faa9007d870) at /data/src/10.4/sql/opt_range.cc:12254
#6  0x000055c0fa61522e in rr_quick (info=0x7faaa261b8d0) at /data/src/10.4/sql/records.cc:369
#7  0x000055c0fa36261e in READ_RECORD::read_record (this=0x7faaa261b8d0) at /data/src/10.4/sql/records.h:70
#8  mysql_update (thd=thd@entry=0x7faa90000c48, table_list=<optimized out>, fields=..., values=..., conds=<optimized out>, order_num=<optimized out>, order=<optimized out>, limit=18446744073709551614, ignore=false, found_return=0x7faaa261bcb0, updated_return=0x7faaa261bd70) at /data/src/10.4/sql/sql_update.cc:993
#9  0x000055c0fa2a5ac5 in mysql_execute_command (thd=0x7faa90000c48) at /data/src/10.4/sql/sql_parse.cc:4407
#10 0x000055c0fa2ac253 in mysql_parse (thd=0x7faa90000c48, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /data/src/10.4/sql/sql_parse.cc:7958
#11 0x000055c0fa2ae80a in dispatch_command (command=COM_QUERY, thd=0x7faa90000c48, packet=<optimized out>, packet_length=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /data/src/10.4/sql/sql_class.h:1170
#12 0x000055c0fa2b0a0a in do_command (thd=0x7faa90000c48) at /data/src/10.4/sql/sql_parse.cc:1373
#13 0x000055c0fa3a397e in do_handle_one_connection (connect=connect@entry=0x55c0fd3c85e8) at /data/src/10.4/sql/sql_connect.cc:1412
#14 0x000055c0fa3a3a9f in handle_one_connection (arg=arg@entry=0x55c0fd3c85e8) at /data/src/10.4/sql/sql_connect.cc:1316
#15 0x000055c0fa9c0d06 in pfs_spawn_thread (arg=0x55c0fd322068) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#16 0x00007faaa8b65609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#17 0x00007faaa8754293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

10.4 d67e17bb debug

mysqld: /data/src/10.4/sql/handler.h:3203: int handler::ha_index_init(uint, bool): Assertion `inited==NONE' failed.
210104 19:20:07 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f88fe054f36 in __GI___assert_fail (assertion=0x557a8bdd032e "inited==NONE", file=0x557a8bdd0303 "/data/src/10.4/sql/handler.h", line=3203, function=0x557a8bdd0340 "int handler::ha_index_init(uint, bool)") at assert.c:101
#8  0x0000557a8b03cbc3 in handler::ha_index_init (this=0x7f88e01a5a78, idx=0, sorted=false) at /data/src/10.4/sql/handler.h:3203
#9  0x0000557a8b46e840 in check_duplicate_long_entry_key (table=0x7f88e01a4c10, h=0x7f88e01a5a78, new_rec=0x7f88e012d740 "\360\003", key_no=0) at /data/src/10.4/sql/handler.cc:6594
#10 0x0000557a8b46ef7b in check_duplicate_long_entries (table=0x7f88e01a4c10, h=0x7f88e01a5a78, new_rec=0x7f88e012d740 "\360\003") at /data/src/10.4/sql/handler.cc:6670
#11 0x0000557a8b46f2ca in handler::ha_write_row (this=0x7f88e01a5a78, buf=0x7f88e012d740 "\360\003") at /data/src/10.4/sql/handler.cc:6750
#12 0x0000557a8b0a7518 in vers_insert_history_row (table=0x7f88e01a4c10) at /data/src/10.4/sql/sql_insert.cc:1689
#13 0x0000557a8b2087aa in mysql_update (thd=0x7f88e0000d90, table_list=0x7f88e0013540, fields=..., values=..., conds=0x7f88e00148c8, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f88ebffde20, updated_return=0x7f88ebffdee0) at /data/src/10.4/sql/sql_update.cc:1111
#14 0x0000557a8b0f3b00 in mysql_execute_command (thd=0x7f88e0000d90) at /data/src/10.4/sql/sql_parse.cc:4407
#15 0x0000557a8b0ffd19 in mysql_parse (thd=0x7f88e0000d90, rawbuf=0x7f88e0013458 "UPDATE t1 SET a = 3 WHERE b <= 10", length=33, parser_state=0x7f88ebffe550, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7958
#16 0x0000557a8b0ec041 in dispatch_command (command=COM_QUERY, thd=0x7f88e0000d90, packet=0x7f88e00087b1 "UPDATE t1 SET a = 3 WHERE b <= 10", packet_length=33, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1855
#17 0x0000557a8b0ea8a9 in do_command (thd=0x7f88e0000d90) at /data/src/10.4/sql/sql_parse.cc:1373
#18 0x0000557a8b279b93 in do_handle_one_connection (connect=0x557a8d7640f0) at /data/src/10.4/sql/sql_connect.cc:1412
#19 0x0000557a8b2798dc in handle_one_connection (arg=0x557a8d7640f0) at /data/src/10.4/sql/sql_connect.cc:1316
#20 0x0000557a8bc9a768 in pfs_spawn_thread (arg=0x557a8d6b1920) at /data/src/10.4/storage/perfschema/pfs.cc:1869
#21 0x00007f88fe8d5609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#22 0x00007f88fe140293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

The test case is not applicable to 10.3 due to the use of unique blobs.
The failure started happening on 10.4 after this merge:

commit 0aa02567dd62d96467f84ba96cc67b103f63c9e0
Merge: 04741dc736e fa1aef39ebc
Author: Marko Mäkelä
Date:   Wed Dec 23 14:52:59 2020 +0200
 
    Merge 10.3 into 10.4

my guess is due to this commit

Author: Aleksey Midenkov
Date:   Tue Dec 22 08:34:18 2020 +0300
 
    MDEV-23446 UPDATE does not insert history row if the row is not changed

but it could be just because it allows the 2nd UPDATE in the test case to do something, I can't say whether it's the actual root cause of the problem.

10.5 doesn't fail as of now, as the patch above hasn't been merged into 10.5 yet.



 Comments   
Comment by Elena Stepanova [ 2021-01-04 ]

I have set it to Critical as a possible regression. Please feel free to demote and remove the label if the analysis reveals that the underlying problem existed before.

Comment by Aleksey Midenkov [ 2021-01-20 ]

Please review https://github.com/MariaDB/server/commit/0f56fece7cd10300554c6df23d97d02ced0debb0 in bb-10.4-midenok

Comment by Oleksandr Byelkin [ 2021-01-25 ]

OK to push.

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