[MDEV-18960] Assertion `!omits_virtual_cols(*form->s)' failed after upgrade from 10.0/10.1 with PERSISTENT generated column Created: 2019-03-18  Updated: 2019-04-01  Resolved: 2019-03-19

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Virtual Columns
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.2.23, 10.3.14, 10.4.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Attachments: File data.tar.gz    
Issue Links:
Relates
relates to MDEV-13564 TRUNCATE TABLE and undo tablespace tr... Closed
relates to MDEV-17199 Assertion `pos < table->n_v_def' fail... Closed
relates to MDEV-18966 Transaction recovery may be broken af... Closed

 Description   

To reproduce,

  • On 10.0/10.1 with all default options, run 

    create table t1 (a int, b int generated always as (a) persistent) engine=InnoDB;

  • shut down the server normally;
  • start 10.2+ on the same datadir;
  • [optionally] run mysql_upgrade (doesn't make any difference for the failure on TRUNCATE, but see the footnote);
  • run 

    truncate table t1;

10.4 09b2d37a

 
mysqld: /data/src/10.4/storage/innobase/handler/ha_innodb.cc:10733: bool create_table_check_doc_id_col(trx_t*, const TABLE*, ulint*): Assertion `!omits_virtual_cols(*form->s)' failed.
 
190318 20:23:53 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f410c1ccee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x0000560e1fd64ec4 in create_table_check_doc_id_col (trx=0x7f4108eda390, form=0x7f409806fe80, doc_id_col=0x7f4108e3f8e8) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:10733
 
#9  0x0000560e1fd7a4f7 in create_table_info_t::create_table_def (this=0x7f4108e3fd60) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:10963
 
#10 0x0000560e1fd6744f in create_table_info_t::create_table (this=0x7f4108e3fd60, create_fk=false) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:12401
 
#11 0x0000560e1fd7bcb8 in ha_innobase::create (this=0x7f40981ca5d8, name=0x7f40982f24a0 "test/t1", form=0x7f409806fe80, create_info=0x7f4108e40270, file_per_table=true, trx=0x7f4108eda390) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:12719
 
#12 0x0000560e1fd68f13 in ha_innobase::truncate (this=0x7f40981ca5d8) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:13393
 
#13 0x0000560e1fa24e05 in handler::ha_truncate (this=0x7f40981ca5d8) at /data/src/10.4/sql/handler.cc:4562
 
#14 0x0000560e1f882b20 in Sql_cmd_truncate_table::handler_truncate (this=0x7f4098014a00, thd=0x7f4098000b00, table_ref=0x7f4098014358, is_tmp_table=false) at /data/src/10.4/sql/sql_truncate.cc:242
 
#15 0x0000560e1f88325a in Sql_cmd_truncate_table::truncate_table (this=0x7f4098014a00, thd=0x7f4098000b00, table_ref=0x7f4098014358) at /data/src/10.4/sql/sql_truncate.cc:450
 
#16 0x0000560e1f8833e8 in Sql_cmd_truncate_table::execute (this=0x7f4098014a00, thd=0x7f4098000b00) at /data/src/10.4/sql/sql_truncate.cc:506
 
#17 0x0000560e1f6de4dc in mysql_execute_command (thd=0x7f4098000b00) at /data/src/10.4/sql/sql_parse.cc:6394
 
#18 0x0000560e1f6e3675 in mysql_parse (thd=0x7f4098000b00, rawbuf=0x7f4098014288 "truncate table test.t1", length=22, parser_state=0x7f4108e411d0, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8205
 
#19 0x0000560e1f6ceca5 in dispatch_command (command=COM_QUERY, thd=0x7f4098000b00, packet=0x7f409801c361 "truncate table test.t1", packet_length=22, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1829
 
#20 0x0000560e1f6cd48b in do_command (thd=0x7f4098000b00) at /data/src/10.4/sql/sql_parse.cc:1358
 
#21 0x0000560e1f847387 in do_handle_one_connection (connect=0x560e23a13e90) at /data/src/10.4/sql/sql_connect.cc:1399
 
#22 0x0000560e1f8470f8 in handle_one_connection (arg=0x560e23a13e90) at /data/src/10.4/sql/sql_connect.cc:1302
 
#23 0x00007f410dea3494 in start_thread (arg=0x7f4108e42700) at pthread_create.c:333
 
#24 0x00007f410c28993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Footnote

If truncate table was run and crashed without previous mysql_upgrade, 10.3/10.4 refuse to start afterwards:

mysqld: /data/src/10.4/storage/innobase/row/row0undo.cc:389: bool row_undo_rec_get(undo_node_t*): Assertion `undo == update || undo == temp' failed.
 
190318 20:32:51 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007fa3b6936ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x000056153f1d6025 in row_undo_rec_get (node=0x561542c2ed38) at /data/src/10.4/storage/innobase/row/row0undo.cc:389
 
#9  0x000056153f1d614e in row_undo (node=0x561542c2ed38, thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/row/row0undo.cc:414
 
#10 0x000056153f1d6424 in row_undo_step (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/row/row0undo.cc:498
 
#11 0x000056153f1368b2 in que_thr_step (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/que/que0que.cc:1040
 
#12 0x000056153f136b01 in que_run_threads_low (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/que/que0que.cc:1104
 
#13 0x000056153f136cf2 in que_run_threads (thr=0x561542c2eb68) at /data/src/10.4/storage/innobase/que/que0que.cc:1144
 
#14 0x000056153f234e9c in trx_rollback_active (trx=0x7fa3a10dd140) at /data/src/10.4/storage/innobase/trx/trx0roll.cc:663
 
#15 0x000056153f23568b in trx_rollback_recovered (all=false) at /data/src/10.4/storage/innobase/trx/trx0roll.cc:819
 
#16 0x000056153f1fc395 in srv_start (create_new_db=false) at /data/src/10.4/storage/innobase/srv/srv0start.cc:2114
 
#17 0x000056153f022a58 in innodb_init (p=0x561541cd35f0) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:4285
 
#18 0x000056153ece6ed9 in ha_initialize_handlerton (plugin=0x561541cc4878) at /data/src/10.4/sql/handler.cc:531
 
#19 0x000056153e9bb92b in plugin_initialize (tmp_root=0x7ffc511e5960, plugin=0x561541cc4878, argc=0x561540226078 <remaining_argc>, argv=0x561541c61d68, options_only=false) at /data/src/10.4/sql/sql_plugin.cc:1437
 
#20 0x000056153e9bc5c0 in plugin_init (argc=0x561540226078 <remaining_argc>, argv=0x561541c61d68, flags=2) at /data/src/10.4/sql/sql_plugin.cc:1720
 
#21 0x000056153e86dbf9 in init_server_components () at /data/src/10.4/sql/mysqld.cc:5176
 
#22 0x000056153e86eddf in mysqld_main (argc=11, argv=0x561541c61d68) at /data/src/10.4/sql/mysqld.cc:5703
 
#23 0x000056153e863460 in main (argc=11, argv=0x7ffc511e63a8) at /data/src/10.4/sql/main.cc:25

(Possibly it's not mysql_upgrade as such that's important, but any activity before truncate).

Data directory pre-created on 10.1 cd805a5f is attached as data.tar.gz.

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

The assertion that was added in MDEV-17199 is conflicting with the TRUNCATE TABLE implementation of MDEV-13564. Because the .frm file will not change in TRUNCATE, InnoDB must be prepared to create a table with ‘old-format’ metadata.

When the failing assertion is removed, the TRUNCATE will proceed without a crash. Alas, if we define a slightly different table before upgrading, the table would fail to load after TRUNCATE:

create table t2 (a int, b int as (a) virtual) engine=innodb;
 
--echo # upgrade to 10.2+
 
truncate table t2;

This would lead to an error message being issued to the client:

ERROR 1932 (42S02): Table 'test.t2' doesn't exist in engine

and another message being emitted to the server error log:

2019-03-19 9:33:28 8 [Warning] InnoDB: Table test/t2 contains 2 user defined columns in InnoDB, but 1 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

When it comes to the 10.3 assertion failure after the initial crash, it appears that the trx->rsegs.m_redo.undo that the TRUNCATE transaction did write before the server crashed was incorrectly recovered as trx->rsegs.m_redo.old_insert. This could be a regression that affects any upgrade to 10.3. Basically, a follow-up fix to MDEV-12288 is needed. MDEV-15912 documents another such problem.

Comment by Marko Mäkelä [ 2019-03-19 ]

I filed MDEV-18966 for the 10.3+ recovery problem.

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