[MDEV-21007] Assertion `auto_increment_value' failed in ha_partition::info upon UPDATE with partition pruning Created: 2019-11-08  Updated: 2023-12-04

Status: Stalled
Project: MariaDB Server
Component/s: Partitioning
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11
Fix Version/s: 10.4, 10.5, 10.6, 10.11, 11.0

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Yuchen Pei
Resolution: Unresolved Votes: 0
Labels: regression

Issue Links:
Relates
relates to MDEV-21027 Assertion `part_share->auto_inc_initi... Closed
relates to MDEV-11011 Assertion `auto_increment_value' fail... Closed
relates to MDEV-24610 Assertion `auto_increment_value' fail... Confirmed
relates to MDEV-31217 Assertion `auto_increment_value' fail... Open

 Description    

--source include/have_partition.inc
 
 
 
CREATE TABLE t1 (a INT) PARTITION BY RANGE (a) (PARTITION p0 VALUES LESS THAN (1), PARTITION p1 VALUES LESS THAN (MAXVALUE));
 
INSERT INTO t1 VALUES (1),(2);
 
ALTER TABLE t1 MODIFY a INT AUTO_INCREMENT PRIMARY KEY;
 
UPDATE t1 PARTITION (p1) SET a=9 ORDER BY a LIMIT 1;
 
 
 
# Cleanup
 
DROP TABLE t1;

10.3 352e7667

 
mysqld: /data/src/10.3/sql/ha_partition.cc:8190: virtual int ha_partition::info(uint): Assertion `auto_increment_value' failed.
 
191108  2:54:29 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f67b2f31f12 in __GI___assert_fail (assertion=0x5566f0fa9739 "auto_increment_value", file=0x5566f0fa6e20 "/data/src/10.3/sql/ha_partition.cc", line=8190, function=0x5566f0fab860 <ha_partition::info(unsigned int)::__PRETTY_FUNCTION__> "virtual int ha_partition::info(uint)") at assert.c:101
 
#8  0x00005566f0b441c2 in ha_partition::info (this=0x7f679c095d38, flag=64) at /data/src/10.3/sql/ha_partition.cc:8190
 
#9  0x00005566f0b48ff7 in ha_partition::update_next_auto_inc_val (this=0x7f679c095d38) at /data/src/10.3/sql/ha_partition.cc:10357
 
#10 0x00005566f0b39695 in ha_partition::update_row (this=0x7f679c095d38, old_data=0x7f679c16de90 "\377\001", new_data=0x7f679c16de88 "\377\t") at /data/src/10.3/sql/ha_partition.cc:4474
 
#11 0x00005566f031e516 in handler::ha_update_row (this=0x7f679c095d38, old_data=0x7f679c16de90 "\377\001", new_data=0x7f679c16de88 "\377\t") at /data/src/10.3/sql/handler.cc:6478
 
#12 0x00005566f00fa8f8 in mysql_update (thd=0x7f679c000af0, table_list=0x7f679c012970, fields=..., values=..., conds=0x0, order_num=1, order=0x7f679c0132c0, limit=1, ignore=false, found_return=0x7f67ad12ff10, updated_return=0x7f67ad12ffd0) at /data/src/10.3/sql/sql_update.cc:954
 
#13 0x00005566efff755b in mysql_execute_command (thd=0x7f679c000af0) at /data/src/10.3/sql/sql_parse.cc:4301
 
#14 0x00005566f0003597 in mysql_parse (thd=0x7f679c000af0, rawbuf=0x7f679c012808 "UPDATE t1 PARTITION (p1) SET a=9 ORDER BY a LIMIT 1", length=51, parser_state=0x7f67ad1305e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7815
 
#15 0x00005566efff011b in dispatch_command (command=COM_QUERY, thd=0x7f679c000af0, packet=0x7f679c008c61 "UPDATE t1 PARTITION (p1) SET a=9 ORDER BY a LIMIT 1", packet_length=51, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
 
#16 0x00005566effeea63 in do_command (thd=0x7f679c000af0) at /data/src/10.3/sql/sql_parse.cc:1401
 
#17 0x00005566f0165bea in do_handle_one_connection (connect=0x5566f29cf340) at /data/src/10.3/sql/sql_connect.cc:1403
 
#18 0x00005566f016594c in handle_one_connection (arg=0x5566f29cf340) at /data/src/10.3/sql/sql_connect.cc:1308
 
#19 0x00005566f0b14718 in pfs_spawn_thread (arg=0x5566f29ea300) at /data/src/10.3/storage/perfschema/pfs.cc:1862
 
#20 0x00007f67b4aa74a4 in start_thread (arg=0x7f67ad131700) at pthread_create.c:456
 
#21 0x00007f67b2feed0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible with at least InnoDB and MyISAM on 10.3-10.4.
Not reproducible on 10.2.
No obvious effect on a non-debug build.

The failure appeared in 10.3 after this commit:

commit 6dce6aecebe6ef78a14cb5c5c5daa8a355551e40
 
Author: Alexey Botchkov <holyfoot@askmonty.org>
 
Date:   Fri Nov 1 09:39:43 2019 +0400
 
 
 
    MDEV-18244 Server crashes in ha_innobase::update_thd / ... / ha_partition::update_next_auto_inc_val.



 Comments   
Comment by Yuchen Pei [ 2022-12-14 ]

Commit 6dce6aecebe6ef78a14cb5c5c5daa8a355551e40 does not build (in both 10.3 and 10.4), probably because it is too old:

[ 67%] Building C object storage/maria/CMakeFiles/aria.dir/ma_servicethread.c.o
 
/home/ycp/source/mariadb-server/10.4/src/storage/maria/ma_pagecrc.c: In function ‘maria_page_crc_check_index’:
 
/home/ycp/source/mariadb-server/10.4/src/storage/maria/ma_pagecrc.c:254:21: error: overflow in conversion from ‘int’ to ‘my_bool’ {aka ‘char’} changes value from ‘_my_thread_var()->thr_errno = 176’ to ‘-80’ [-Werror=overflow]
 
  254 |     return (my_errno= HA_ERR_WRONG_CRC);
 
      |            ~~~~~~~~~^~~~~~~~~~~~~~~~~~~
 
cc1: all warnings being treated as errors
 
gmake[2]: *** [storage/maria/CMakeFiles/aria.dir/build.make:927: storage/maria/CMakeFiles/aria.dir/ma_pagecrc.c.o] Error 1
 
gmake[2]: *** Waiting for unfinished jobs....

Comment by Yuchen Pei [ 2022-12-14 ]

Am able to build with -DMYSQL_MAINTAINER_MODE=OFF

Comment by Yuchen Pei [ 2022-12-14 ]

the immediate cause is that some added lines in the culprit commit causes a break out of the do-while loop, so that the auto_increment_value remains 0

+          if (!bitmap_is_set(&m_opened_partitions, (uint)(file_array - m_file)))
 
+          {
 
+            /*
 
+              Some partitions aren't opened.
 
+              So we can't calculate the autoincrement.
 
+            */
 
+            all_parts_opened= false;
 
+            break;
 
+          }
 
           file= *file_array;
 
           file->info(HA_STATUS_AUTO | no_lock_flag);
 
           set_if_bigger(auto_increment_value,
 
@@ -8182,7 +8189,7 @@ int ha_partition::info(uint flag)
 
 
         DBUG_ASSERT(auto_increment_value);

Comment by Yuchen Pei [ 2022-12-14 ]

A simple fix that does the assert only if all_parts_opened. What do you think holyfoot?

https://github.com/MariaDB/server/commit/c758eda7d43d1a83ca975796a8893424104f6443

Comment by Roel Van de Paar [ 2022-12-15 ]

Confirmed issue exists in 10.3-10.11 debug builds

10.11.2 936436ef437c73911c18854a8ce8dad1216331b8 (Debug)

 
mysqld: /test/10.11_dbg/sql/ha_partition.cc:8560: virtual int ha_partition::info(uint): Assertion `auto_increment_value' failed.

10.11.2 936436ef437c73911c18854a8ce8dad1216331b8 (Debug)

 
Core was generated by `/test/MD291122-mariadb-10.11.2-linux-x86_64-dbg/bin/mysqld --no-defaults --core'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
[Current thread is 1 (Thread 0x14ba95340700 (LWP 1319659))]
 
(gdb) bt
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
#1  0x000014bab32a4859 in __GI_abort () at abort.c:79
 
#2  0x000014bab32a4729 in __assert_fail_base (fmt=0x14bab343a588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55ba4a224717 "auto_increment_value", file=0x55ba4a224a18 "/test/10.11_dbg/sql/ha_partition.cc", line=8560, function=<optimized out>) at assert.c:92
 
#3  0x000014bab32b5fd6 in __GI___assert_fail (assertion=assertion@entry=0x55ba4a224717 "auto_increment_value", file=file@entry=0x55ba4a224a18 "/test/10.11_dbg/sql/ha_partition.cc", line=line@entry=8560, function=function@entry=0x55ba4a225558 "virtual int ha_partition::info(uint)") at assert.c:101
 
#4  0x000055ba499ecd75 in ha_partition::info (this=this@entry=0x14ba38020f50, flag=flag@entry=64) at /test/10.11_dbg/sql/ha_partition.cc:8560
 
#5  0x000055ba499fa678 in ha_partition::update_next_auto_inc_val (this=this@entry=0x14ba38020f50) at /test/10.11_dbg/sql/ha_partition.cc:10781
 
#6  0x000055ba499fafbd in ha_partition::update_row (this=0x14ba38020f50, old_data=<optimized out>, new_data=<optimized out>) at /test/10.11_dbg/sql/ha_partition.cc:4711
 
#7  0x000055ba4975f6b7 in handler::ha_update_row (this=0x14ba38020f50, old_data=0x14ba3802b5d8 "\377\001", new_data=0x14ba3802b5d0 "\377\t") at /test/10.11_dbg/sql/handler.cc:7626
 
#8  0x000055ba4957a0a8 in mysql_update (thd=thd@entry=0x14ba38000d48, table_list=<optimized out>, fields=@0x14ba38005a58: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14ba38013b50, last = 0x14ba38013b50, elements = 1}, <No data fields>}, values=@0x14ba38005e88: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x14ba38013b60, last = 0x14ba38013b60, elements = 1}, <No data fields>}, conds=<optimized out>, order_num=<optimized out>, order=<optimized out>, limit=1, ignore=<optimized out>, found_return=<optimized out>, updated_return=<optimized out>) at /test/10.11_dbg/sql/sql_update.cc:1099
 
#9  0x000055ba49478642 in mysql_execute_command (thd=thd@entry=0x14ba38000d48, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.11_dbg/sql/sql_limit.h:85
 
#10 0x000055ba494655a6 in mysql_parse (thd=thd@entry=0x14ba38000d48, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14ba9533f300) at /test/10.11_dbg/sql/sql_parse.cc:7998
 
#11 0x000055ba49472ae1 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x14ba38000d48, packet=packet@entry=0x14ba3800adf9 "UPDATE t1 PARTITION (p1) SET a=9 ORDER BY a LIMIT 1", packet_length=packet_length@entry=51, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_class.h:1346
 
#12 0x000055ba49474f1f in do_command (thd=0x14ba38000d48, blocking=blocking@entry=true) at /test/10.11_dbg/sql/sql_parse.cc:1407
 
#13 0x000055ba495cfb27 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55ba4cdf5928, put_in_cache=put_in_cache@entry=true) at /test/10.11_dbg/sql/sql_connect.cc:1415
 
#14 0x000055ba495cfff6 in handle_one_connection (arg=0x55ba4cdf5928) at /test/10.11_dbg/sql/sql_connect.cc:1317
 
#15 0x000014bab37b5609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#16 0x000014bab33a1133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Comment by Alexey Botchkov [ 2023-12-04 ]

See the comment at the fix.
With that, ok to push.

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