[MDEV-18869] Assertion `!((field)->vcol_info && (field)->stored_in_db())' failed in innodb_col_no upon altering table with system versioning Created: 2019-03-09  Updated: 2019-03-26  Resolved: 2019-03-26

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB, Versioned Tables
Affects Version/s: 10.3, 10.4
Fix Version/s: 10.3.14, 10.4.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-19029 Better handling of system versioning ... Open

 Description    

--source include/have_innodb.inc
 
 
 
CREATE OR REPLACE TABLE t1 (a INT, b INT GENERATED ALWAYS AS (0) STORED) ENGINE=InnoDB WITH SYSTEM VERSIONING;
 
SET system_versioning_alter_history= KEEP;
 
ALTER TABLE t1 MODIFY a INT WITH SYSTEM VERSIONING;
 
 
 
# Cleanup
 
DROP TABLE t1;

10.4 89b463ee

 
mysqld: /data/src/10.3/storage/innobase/handler/ha_innodb.cc:6389: unsigned int innodb_col_no(const Field*): Assertion `!((field)->vcol_info && (field)->stored_in_db())' failed.
 
190309 15:25:13 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007fa9a9c49ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x0000564dd97dbe5c in innodb_col_no (field=0x7fa95000a8d0) at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:6389
 
#9  0x0000564dd98228e0 in vers_change_fields_cache (ha_alter_info=0x7fa99ef508b0, ctx=0x7fa9500168f0, table=0x7fa95000cb80) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:8628
 
#10 0x0000564dd982bd31 in commit_cache_norebuild (ha_alter_info=0x7fa99ef508b0, ctx=0x7fa9500168f0, table=0x7fa95000cb80, trx=0x7fa9a42881c8) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:9284
 
#11 0x0000564dd9824bb1 in ha_innobase::commit_inplace_alter_table (this=0x7fa9500a6f18, altered_table=0x7fa950182300, ha_alter_info=0x7fa99ef508b0, commit=true) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:9914
 
#12 0x0000564dd94c599c in handler::ha_commit_inplace_alter_table (this=0x7fa9500a6f18, altered_table=0x7fa950182300, ha_alter_info=0x7fa99ef508b0, commit=true) at /data/src/10.3/sql/handler.cc:4538
 
#13 0x0000564dd929a24a in mysql_inplace_alter_table (thd=0x7fa950000b00, table_list=0x7fa950014e10, table=0x7fa95000cb80, altered_table=0x7fa950182300, ha_alter_info=0x7fa99ef508b0, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7fa99ef50ae0, alter_ctx=0x7fa99ef51090) at /data/src/10.3/sql/sql_table.cc:7593
 
#14 0x0000564dd92a03c4 in mysql_alter_table (thd=0x7fa950000b00, new_db=0x7fa9500051d0, new_name=0x7fa950005590, create_info=0x7fa99ef51c80, table_list=0x7fa950014e10, alter_info=0x7fa99ef51bc0, order_num=0, order=0x0, ignore=false) at /data/src/10.3/sql/sql_table.cc:9758
 
#15 0x0000564dd9328591 in Sql_cmd_alter_table::execute (this=0x7fa950015578, thd=0x7fa950000b00) at /data/src/10.3/sql/sql_alter.cc:497
 
#16 0x0000564dd91c96de in mysql_execute_command (thd=0x7fa950000b00) at /data/src/10.3/sql/sql_parse.cc:6335
 
#17 0x0000564dd91ce7a0 in mysql_parse (thd=0x7fa950000b00, rawbuf=0x7fa950014cf8 "ALTER TABLE t1 MODIFY a INT WITH SYSTEM VERSIONING", length=50, parser_state=0x7fa99ef535f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8142
 
#18 0x0000564dd91bb88b in dispatch_command (command=COM_QUERY, thd=0x7fa950000b00, packet=0x7fa950162281 "ALTER TABLE t1 MODIFY a INT WITH SYSTEM VERSIONING", packet_length=50, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1854
 
#19 0x0000564dd91ba275 in do_command (thd=0x7fa950000b00) at /data/src/10.3/sql/sql_parse.cc:1396
 
#20 0x0000564dd9322b1b in do_handle_one_connection (connect=0x564ddc5d7df0) at /data/src/10.3/sql/sql_connect.cc:1403
 
#21 0x0000564dd932289f in handle_one_connection (arg=0x564ddc5d7df0) at /data/src/10.3/sql/sql_connect.cc:1309
 
#22 0x0000564dd97bf141 in pfs_spawn_thread (arg=0x564ddc51d180) at /data/src/10.3/storage/perfschema/pfs.cc:1862
 
#23 0x00007fa9ab920494 in start_thread (arg=0x7fa99ef54700) at pthread_create.c:333
 
#24 0x00007fa9a9d0693f in clone () from /lib/x86_64-linux-gnu/libc.so.6

No obvious effect on a non-debug build.

 Comments   
Comment by Marko Mäkelä [ 2019-03-21 ]

Please test with some data inside the table, and with ALGORITHM=COPY as well.

I did not quite understand this. Are generated columns supposed to never be system versioned, even when they are stored inside the table? If so, what is the technical reason for that?

Please test the following too:

ALTER TABLE t1 MODIFY b WITH SYSTEM VERSIONING;
 
ALTER TABLE t1 MODIFY b WITHOUT SYSTEM VERSIONING;
 
ALTER TABLE t1 MODIFY b WITH SYSTEM VERSIONING, ALGORITHM=COPY;
 
ALTER TABLE t1 MODIFY b WITHOUT SYSTEM VERSIONING, ALGORITHM=COPY;

Comment by Aleksey Midenkov [ 2019-03-23 ]

Generated stored columns are supposed to be always system versioned. WITH/WITHOUT SYSTEM VERSIONING is not supported for generated columns at parser level:

field_def:
 
          opt_attribute
 
        | opt*generated_always AS virtual_column*func
 
         {
 
           Lex->last*field->vcol*info= $3;
 
           Lex->last*field->flags&= ~NOT_NULL*FLAG; // undo automatic NOT NULL for timestamps
 
         }
 
          vcol*opt_specifier vcol_opt*attribute
 
        | opt*generated_always AS ROW_SYM START_SYM opt_asrow*attribute
 
          {
 
            if (Lex->last*field_generated_always_as_row*start())
 
              MYSQL_YYABORT;
 
          }
 
        | opt*generated_always AS ROW_SYM END opt_asrow*attribute
 
          {
 
            if (Lex->last*field_generated_always_as_row*end())
 
              MYSQL_YYABORT;
 
          }
 
        ;

Better feature would be to detect if all the components of generated stored column are WITHOUT SYSTEM VERSIONING and make it so accordingly. Of course independent WITHOUT SYSTEM VERSIONING for generated stored also makes sense. Both these features are of low importance.

Generated at Thu Feb 08 08:47:21 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.