[MDEV-18869] Assertion `!((field)->vcol_info && (field)->stored_in_db())' failed in innodb_col_no upon altering table with system versioning - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.3(EOL), 10.4(EOL)
Fix Version/s: 10.3.14, 10.4.4
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB, Versioned Tables
Labels:
None

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.

Attachments

Issue Links

relates to

MDEV-19029 Better handling of system versioning for generated stored columns

Open

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2019-03-09 13:26

Elena Stepanova made changes - 2019-03-09 13:27

Field	Original Value	New Value
Description	{code:sql} --source include/have_innodb.inc CREATE 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; {code} {noformat:title=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 {noformat} No obvious effect on a non-debug build.	{code:sql} --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; {code} {noformat:title=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 {noformat} No obvious effect on a non-debug build.

Alexander Krizhanovsky made changes - 2019-03-15 15:36

Assignee

Alexander Krizhanovsky [ krizhanovsky ]

Aleksey Midenkov [ midenok ]

Aleksey Midenkov made changes - 2019-03-20 18:14

Status

Open [ 1 ]

In Progress [ 3 ]

Aleksey Midenkov made changes - 2019-03-20 18:15

Assignee	Aleksey Midenkov [ midenok ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Marko Mäkelä added a comment - 2019-03-21 16:07

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;

Marko Mäkelä added a comment - 2019-03-21 16:07 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;

Marko Mäkelä made changes - 2019-03-21 16:07

Assignee	Marko Mäkelä [ marko ]	Aleksey Midenkov [ midenok ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Aleksey Midenkov added a comment - 2019-03-23 13:32

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.

Aleksey Midenkov added a comment - 2019-03-23 13:32 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.

Aleksey Midenkov made changes - 2019-03-23 13:37

Link

This issue relates to MDEV-19029 [ MDEV-19029 ]

Aleksey Midenkov made changes - 2019-03-23 13:55

Status

Stalled [ 10000 ]

In Progress [ 3 ]

Aleksey Midenkov made changes - 2019-03-23 13:56

Assignee	Aleksey Midenkov [ midenok ]	Marko Mäkelä [ marko ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Marko Mäkelä made changes - 2019-03-26 13:43

issue.field.resolutiondate

2019-03-26 13:43:24.0

2019-03-26 13:43:24.899

Marko Mäkelä made changes - 2019-03-26 13:43

Fix Version/s		10.3.14 [ 23216 ]
Fix Version/s		10.4.4 [ 23310 ]
Fix Version/s	10.3 [ 22126 ]
Fix Version/s	10.4 [ 22408 ]
Assignee	Marko Mäkelä [ marko ]	Aleksey Midenkov [ midenok ]
Resolution		Fixed [ 1 ]
Status	In Review [ 10002 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:49

Workflow

MariaDB v3 [ 93065 ]

MariaDB v4 [ 155883 ]

People

Assignee:: Aleksey Midenkov

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2019-03-09 13:26

Updated:: 2019-03-26 13:43

Resolved:: 2019-03-26 13:43

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server