[MDEV-19602] Replace mysql_version check with frm_version for virtual columns inside InnoDB Created: 2019-05-26  Updated: 2019-05-28  Resolved: 2019-05-28

Status: Closed
Project: MariaDB Server
Component/s: Virtual Columns
Affects Version/s: 10.3, 10.4
Fix Version/s: 10.2.25, 10.3.16, 10.4.6

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

Attachments: File data.tar.gz    

 Description   
  • Start 10.1 server, all defaults are sufficient;
  • create a table as 

    CREATE TABLE t1 (f1 INT, f2 INT AS (f1) VIRTUAL) ENGINE=InnoDB;

  • shut down the server normally;
  • start 10.3 or 10.4 server on the same datadir;
  • (optionally, it doesn't affect the outcome) run mysql_upgrade;
  • run 

    CHECK TABLE t1;
    		 
    ALTER TABLE t1 DROP CONSTRAINT IF EXISTS x;

    The result is

    Table	Op	Msg_type	Msg_text
    		 
    test.t1	check	status	OK
    		 
    ERROR 1932 (42S02) at line 2: Table 'test.t1' doesn't exist in engine

    The error log gets the warning:

    2019-05-27  1:49:53 9 [Warning] InnoDB: Table test/t1 contains 1 user defined columns in InnoDB, but 2 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue.

    Further attempts to use the table cause errors in the log:

    2019-05-27  1:50:18 10 [ERROR] InnoDB: Table `test`.`t1` is corrupted. Please drop the table and recreate.

A datadir pre-created as described on 10.1 aaf53ea0 is attached.

Not reproducible with 10.2, either being the new server or old server in the scenario.

 Comments   
Comment by Thirunarayanan Balathandayuthapani [ 2019-05-28 ]

Basically update_frm_version() is being called at the end of check command. So mysql_version got changed to a newer version. It leads to
an inplace alter table for the consecutive alter statement. It fails while doing ha_innobase::open() with column mismatch.

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