[MDEV-32337] Assertion `pos < table->n_def' failed in dict_table_get_nth_col Created: 2023-10-01  Updated: 2023-10-17  Resolved: 2023-10-12

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Virtual Columns
Affects Version/s: 10.4, 10.5, 10.6, 10.10, 10.11, 11.0, 11.1
Fix Version/s: 10.4.32, 10.5.23, 10.6.16, 10.10.7, 10.11.6, 11.0.4, 11.1.3

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Thirunarayanan Balathandayuthapani
Resolution: Fixed Votes: 0
Labels: regression

Issue Links:
Problem/Incident
is caused by MDEV-31086 MODIFY COLUMN can break FK constraint... Closed

 Description    

--source include/have_innodb.inc
 
 
 
CREATE TABLE t (
 
 a INT, va INT AS (a),
 
 b INT, vb INT AS (b),
 
 c INT, vc INT AS (c),
 
 vf VARCHAR(16) AS (f), f VARCHAR(4)
 
) ENGINE=InnoDB;
 
 
 
ALTER TABLE t MODIFY f VARCHAR(8);
 
 
 
# Cleanup
 
DROP TABLE t;

10.4 9b5275b8

 
mysqld: /data/src/10.4/storage/innobase/include/dict0dict.inl:370: dict_col_t* dict_table_get_nth_col(const dict_table_t*, ulint): Assertion `pos < table->n_def' failed.
 
231001 20:25:22 [ERROR] mysqld got signal 6 ;
 
 
 
#9  0x00007f9ef0d74df2 in __GI___assert_fail (assertion=0x5575f4036820 "pos < table->n_def", file=0x5575f4036300 "/data/src/10.4/storage/innobase/include/dict0dict.inl", line=370, function=0x5575f4036860 "dict_col_t* dict_table_get_nth_col(const dict_table_t*, ulint)") at ./assert/assert.c:101
 
#10 0x00005575f2b8d051 in dict_table_get_nth_col (table=0x618000033508, pos=7) at /data/src/10.4/storage/innobase/include/dict0dict.inl:370
 
#11 0x00005575f2bca726 in ha_innobase::prepare_inplace_alter_table (this=0x61d00024aea8, altered_table=0x7f9edc0ca150, ha_alter_info=0x7f9edc0c83e0) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:8351
 
#12 0x00005575f217b56f in handler::ha_prepare_inplace_alter_table (this=0x61d00024aea8, altered_table=0x7f9edc0ca150, ha_alter_info=0x7f9edc0c83e0) at /data/src/10.4/sql/handler.cc:4671
 
#13 0x00005575f1c25e24 in mysql_inplace_alter_table (thd=0x62b00009a208, table_list=0x62b0000a1340, table=0x62000003d088, altered_table=0x7f9edc0ca150, ha_alter_info=0x7f9edc0c83e0, target_mdl_request=0x7f9edc0c8600, alter_ctx=0x7f9edc0c9660) at /data/src/10.4/sql/sql_table.cc:7880
 
#14 0x00005575f1c389f1 in mysql_alter_table (thd=0x62b00009a208, new_db=0x62b00009ea10, new_name=0x62b00009ee68, create_info=0x7f9edc0cb250, table_list=0x62b0000a1340, recreate_info=0x7f9edc0cb0b0, alter_info=0x7f9edc0cb150, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10444
 
#15 0x00005575f1dbf4ea in Sql_cmd_alter_table::execute (this=0x62b0000a1b90, thd=0x62b00009a208) at /data/src/10.4/sql/sql_alter.cc:531
 
#16 0x00005575f19c88f7 in mysql_execute_command (thd=0x62b00009a208) at /data/src/10.4/sql/sql_parse.cc:6218
 
#17 0x00005575f19d4171 in mysql_parse (thd=0x62b00009a208, rawbuf=0x62b0000a1228 "ALTER TABLE t MODIFY f VARCHAR(8)", length=33, parser_state=0x7f9edc0cd860, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8012
 
#18 0x00005575f19aa400 in dispatch_command (command=COM_QUERY, thd=0x62b00009a208, packet=0x62900029e209 "ALTER TABLE t MODIFY f VARCHAR(8)", packet_length=33, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1857
 
#19 0x00005575f19a6f6f in do_command (thd=0x62b00009a208) at /data/src/10.4/sql/sql_parse.cc:1378
 
#20 0x00005575f1da6876 in do_handle_one_connection (connect=0x608000000ba8) at /data/src/10.4/sql/sql_connect.cc:1420
 
#21 0x00005575f1da618d in handle_one_connection (arg=0x608000000ba8) at /data/src/10.4/sql/sql_connect.cc:1324
 
#22 0x00005575f2a17990 in pfs_spawn_thread (arg=0x615000006208) at /data/src/10.4/storage/perfschema/pfs.cc:1869
 
#23 0x00007f9ef0dc8fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
 
#24 0x00007f9ef0e495bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

The failure started happening after this commit in 10.4.31:

commit 5f09b53bdb4e973e7c7ec2c53a24c98321223f98
 
Author: Thirunarayanan Balathandayuthapani
 
Date:   Mon Jun 5 19:09:38 2023 +0530
 
 
 
    MDEV-31086 MODIFY COLUMN can break FK constraints, and lead to unrestorable dumps



 Comments   
Comment by Thirunarayanan Balathandayuthapani [ 2023-10-04 ]

Patch is in bb-10.4-thiru

Comment by Marko Mäkelä [ 2023-10-11 ]

Looks good to me.

Comment by Marko Mäkelä [ 2023-10-13 ]

For the record, the fix extended the regression test with something similar to the following, to document a pre-existing limitation:

--source include/have_innodb.inc
 
CREATE TABLE t (f VARCHAR(4), vf VARCHAR(16) AS (f)) ENGINE=InnoDB;
 
--error ER_UNSUPPORTED_ACTION_ON_GENERATED_COLUMN
 
ALTER TABLE t MODIFY vf VARCHAR(8), ALGORITHM=INPLACE;
 
DROP TABLE t;

The failing assertion is only enabled in debug builds. In release builds, I think that a crash is unlikely, but this could lead to incorrect outcome of the MDEV-31086 debug check, that is, a valid ALTER TABLE could be wrongly refused, or an invalid one could be wrongly allowed to break FOREIGN KEY constraints.

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