[MDEV-25550] Assertion `ctx->skip_pk_sort' failed in bool prepare_inplace_alter_table_dict(Alter_inplace_info*, const TABLE*, const TABLE*, const char*, ulint, ulint, ulint, bool, bool) Created: 2021-04-28  Updated: 2021-04-28  Resolved: 2021-04-28

Status: Closed
Project: MariaDB Server
Component/s: Debug
Affects Version/s: 10.2, 10.3, 10.4, 10.5, 10.6
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Ramesh Sivaraman Assignee: Marko Mäkelä
Resolution: Not a Bug Votes: 0
Labels: None


 Description    

SET DEBUG_DBUG='+d,innodb_alter_table_pk_assert_no_sort';
 
CREATE TABLE t1(c1 TIMESTAMP) ENGINE=INNODB;
 
CREATE UNIQUE INDEX i12 ON t1(c1);

Leads to:

10.6.0 8dd35a2507f8d63ca8df9335d2c6072d5c0e3b86 (Debug)

 
mysqld: /test/10.6_dbg/storage/innobase/handler/handler0alter.cc:6886: bool prepare_inplace_alter_table_dict(Alter_inplace_info*, const TABLE*, const TABLE*, const char*, ulint, ulint, ulint, bool, bool): Assertion `ctx->skip_pk_sort' failed.

10.6.0 8dd35a2507f8d63ca8df9335d2c6072d5c0e3b86 (Debug)

 
Core was generated by `/test/MD160321-mariadb-10.6.0-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6)
 
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
 
[Current thread is 1 (Thread 0x1553ac060700 (LWP 4065783))]
 
(gdb) bt
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
 
#1  0x000055725d2ded0b in my_write_core (sig=sig@entry=6) at /test/10.6_dbg/mysys/stacktrace.c:424
 
#2  0x000055725ca76313 in handle_fatal_signal (sig=6) at /test/10.6_dbg/sql/signal_handler.cc:331
 
#3  <signal handler called>
 
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
#5  0x00001553ae40a859 in __GI_abort () at abort.c:79
 
#6  0x00001553ae40a729 in __assert_fail_base (fmt=0x1553ae5a0588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55725d6a0e40 "ctx->skip_pk_sort", file=0x55725d69c268 "/test/10.6_dbg/storage/innobase/handler/handler0alter.cc", line=6886, function=<optimized out>) at assert.c:92
 
#7  0x00001553ae41bf36 in __GI___assert_fail (assertion=assertion@entry=0x55725d6a0e40 "ctx->skip_pk_sort", file=file@entry=0x55725d69c268 "/test/10.6_dbg/storage/innobase/handler/handler0alter.cc", line=line@entry=6886, function=function@entry=0x55725d69df48 "bool prepare_inplace_alter_table_dict(Alter_inplace_info*, const TABLE*, const TABLE*, const char*, ulint, ulint, ulint, bool, bool)") at assert.c:101
 
#8  0x000055725cea8ada in prepare_inplace_alter_table_dict (ha_alter_info=ha_alter_info@entry=0x1553ac05d240, altered_table=altered_table@entry=0x1553ac05d2f0, old_table=<optimized out>, table_name=<optimized out>, flags=<optimized out>, flags2=<optimized out>, fts_doc_id_col=<optimized out>, add_fts_doc_id=<optimized out>, add_fts_doc_id_idx=<optimized out>) at /test/10.6_dbg/storage/innobase/handler/handler0alter.cc:6885
 
#9  0x000055725cead60a in ha_innobase::prepare_inplace_alter_table (this=<optimized out>, altered_table=<optimized out>, ha_alter_info=<optimized out>) at /test/10.6_dbg/storage/innobase/handler/ha_innodb.h:707
 
#10 0x000055725ca845cd in handler::ha_prepare_inplace_alter_table (this=0x155360027640, altered_table=altered_table@entry=0x1553ac05d2f0, ha_alter_info=ha_alter_info@entry=0x1553ac05d240) at /test/10.6_dbg/sql/handler.cc:4836
 
#11 0x000055725c87e459 in mysql_inplace_alter_table (thd=thd@entry=0x155360000db8, table_list=0x155360013c90, table=table@entry=0x155360020e08, altered_table=altered_table@entry=0x1553ac05d2f0, ha_alter_info=ha_alter_info@entry=0x1553ac05d240, target_mdl_request=target_mdl_request@entry=0x1553ac05d840, alter_ctx=0x1553ac05e3a0) at /test/10.6_dbg/sql/sql_table.cc:8105
 
#12 0x000055725c89247c in mysql_alter_table (thd=thd@entry=0x155360000db8, new_db=new_db@entry=0x155360013ca8, new_name=new_name@entry=0x155360013cb8, create_info=create_info@entry=0x1553ac05f000, table_list=<optimized out>, table_list@entry=0x155360013c90, alter_info=alter_info@entry=0x1553ac05ef10, order_num=0, order=0x0, ignore=false, if_exists=false) at /test/10.6_dbg/sql/sql_table.cc:10779
 
#13 0x000055725c7b9b87 in mysql_execute_command (thd=thd@entry=0x155360000db8) at /test/10.6_dbg/sql/structs.h:563
 
#14 0x000055725c7a5876 in mysql_parse (thd=thd@entry=0x155360000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1553ac05f410) at /test/10.6_dbg/sql/sql_parse.cc:7998
 
#15 0x000055725c7b41e7 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x155360000db8, packet=packet@entry=0x15536000b359 "CREATE UNIQUE INDEX i12 ON t1(c1)", packet_length=packet_length@entry=33, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_class.h:1318
 
#16 0x000055725c7b75c1 in do_command (thd=0x155360000db8, blocking=blocking@entry=true) at /test/10.6_dbg/sql/sql_parse.cc:1397
 
#17 0x000055725c90f178 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55726044f2c8, put_in_cache=put_in_cache@entry=true) at /test/10.6_dbg/sql/sql_connect.cc:1410
 
#18 0x000055725c90f77d in handle_one_connection (arg=arg@entry=0x55726044f2c8) at /test/10.6_dbg/sql/sql_connect.cc:1312
 
#19 0x000055725cdbaa5b in pfs_spawn_thread (arg=0x557260373a48) at /test/10.6_dbg/storage/perfschema/pfs.cc:2201
 
#20 0x00001553ae918609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#21 0x00001553ae507293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.2.38 (dbg), 10.3.29 (dbg), 10.4.19 (dbg), 10.5.10 (dbg), 10.6.0 (dbg)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.2.38 (opt), 10.3.29 (opt), 10.4.19 (opt), 10.5.10 (opt), 10.6.0 (opt)

 Comments   
Comment by Sergei Golubchik [ 2021-04-28 ]

ramesh, why Is this a bug?

Comment by Ramesh Sivaraman [ 2021-04-28 ]

serg As per debug symbol innodb_alter_table_pk_assert_no_sort, it is an expected behaviour, the ALTER TABLE should crash if it doesn't do sort operation. Closing this issue as not a bug.

Comment by Marko Mäkelä [ 2021-04-28 ]

For the record, I co-designed and reviewed this optimization in MySQL 5.7. The idea is that we avoid sorting the PRIMARY KEY whenever that is possible. For example, if a column is added to the PRIMARY KEY, say, (a,b) becomes (a,b,c), then the existing sorting will work just fine and we can simply copy from the old clustered index without sorting.

I am wondering a bit why the assertion fails in this case, because this should only create a unique secondary index. Maybe TIMESTAMP implies NOT NULL? In that case the unique index would be promoted to the clustered index key and the table would be rebuilt. And sure enough, because there is no existing primary key, we would have to sort the records, and the assertion is then supposed to fail.

Comment by Ramesh Sivaraman [ 2021-04-28 ]

marko you are right, TIMESTAMP implies NOT NULL.

10.6.0>CREATE TABLE t1(c1 TIMESTAMP) ENGINE=INNODB;
 
Query OK, 0 rows affected (0.014 sec)
 
 
 
10.6.0>SHOW CREATE TABLE t1\G
 
*************************** 1. row ***************************
 
       Table: t1
 
Create Table: CREATE TABLE `t1` (
 
  `c1` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp()
 
) ENGINE=InnoDB DEFAULT CHARSET=latin1
 
1 row in set (0.001 sec)
 
 
 
10.6.0>

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