Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-4442

Definition of ARCHIVE table is not re-discovered after replacing ARZ file

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Not a Bug
    • Affects Version/s: 10.0.2
    • Fix Version/s: 10.0.4
    • Component/s: None
    • Labels:
      None

      Description

      It's not quite clear from the KB whether it should work or not, so I'll file it just in case, please close if it's not a bug

      I create an ARCHIVE table and get the .frm file be created. Then I replace .ARZ file by one from a table with a different definition.
      First, the server (or engine?) does not notice the change at all, e.g. SHOW CREATE keeps showing the old definition.
      After FLUSH TABLES the first access causes ER_TABLE_DEF_CHANGED, which I would expect, but the following actions cause ER_NOT_FORM_FILE which I didn't quite expect.

      On some reason, I couldn't reproduce it via MTR, so the test below is supposed to be executed via MySQL client.
      Please also note that it runs system cp ... in the middle, if it's not suitable for you on whatever reason, please execute it manually instead.

      Output (with comments):

      MariaDB [test]> -- Watch that DROP worked, otherwise there might be garbage in arch
      MariaDB [test]> DROP DATABASE IF EXISTS arch;
      Query OK, 0 rows affected, 1 warning (0.00 sec)
       
      MariaDB [test]> CREATE DATABASE arch;
      Query OK, 1 row affected (0.00 sec)
       
      MariaDB [test]> USE arch;
      Database changed
      MariaDB [arch]> DROP TABLE IF EXISTS t1, t2;
      Query OK, 0 rows affected, 2 warnings (0.01 sec)
       
      MariaDB [arch]> CREATE TABLE t1 (a INT, b INT) ENGINE=ARCHIVE;
      Query OK, 0 rows affected (0.00 sec)
       
      MariaDB [arch]> CREATE TABLE t2 (a INT) ENGINE=ARCHIVE;
      Query OK, 0 rows affected (0.00 sec)
       
      MariaDB [arch]> INSERT INTO t2 VALUES (1);
      Query OK, 1 row affected (0.18 sec)
       
      MariaDB [arch]> -- We now have both t2.ARZ and t2.frm
      MariaDB [arch]> -- cp will only work if the relative path is correct, 
      MariaDB [arch]> -- otherwise fix it or copy the file manually
       
      MariaDB [arch]> system cp data/arch/t1.ARZ data/arch/t2.ARZ
       
      MariaDB [arch]> -- Now we have new .ARZ, but old .frm (with 1 column)
       
      MariaDB [arch]> -- No indication that something has changed
      MariaDB [arch]> SHOW CREATE TABLE t2;
      +-------+----------------------------------------------------------------------------------------+
      | Table | Create Table                                                                           |
      +-------+----------------------------------------------------------------------------------------+
      | t2    | CREATE TABLE `t2` (
        `a` int(11) DEFAULT NULL
      ) ENGINE=ARCHIVE DEFAULT CHARSET=latin1 |
      +-------+----------------------------------------------------------------------------------------+
      1 row in set (0.05 sec)
       
      MariaDB [arch]> FLUSH TABLES;
      Query OK, 0 rows affected (0.01 sec)
       
      MariaDB [arch]> -- First time we get ER_TABLE_DEF_CHANGED, it seems reasonable
      MariaDB [arch]> SHOW CREATE TABLE t2;
      ERROR 1412 (HY000): Table definition has changed, please retry transaction
       
      MariaDB [arch]> -- .. but shouldn't it have been re-discovered?
      MariaDB [arch]> SHOW CREATE TABLE t2;
      ERROR 1033 (HY000): Incorrect information in file: './arch/t2.frm'
       
      MariaDB [arch]> -- and DROP doesn't work either
      MariaDB [arch]> DROP TABLE t2;
      Query OK, 0 rows affected, 1 warning (0.00 sec)
       
      MariaDB [arch]> show warnings;
      +-------+------+------------------------------------------------+
      | Level | Code | Message                                        |
      +-------+------+------------------------------------------------+
      | Error | 1033 | Incorrect information in file: './arch/t2.frm' |
      +-------+------+------------------------------------------------+
      1 row in set (0.00 sec)
       
      MariaDB [arch]> show tables;
      +----------------+
      | Tables_in_arch |
      +----------------+
      | t1             |
      | t2             |
      +----------------+
      2 rows in set (0.00 sec)
       

      SQL:

      -- Watch that DROP worked, otherwise there might be garbage in arch
      DROP DATABASE IF EXISTS arch;
       
      CREATE DATABASE arch;
      USE arch;
      DROP TABLE IF EXISTS t1, t2;
      CREATE TABLE t1 (a INT, b INT) ENGINE=ARCHIVE;
      CREATE TABLE t2 (a INT) ENGINE=ARCHIVE;
      INSERT INTO t2 VALUES (1);
       
      -- We now have both t2.ARZ and t2.frm
      -- cp will only work if the relative path is correct, 
      -- otherwise fix it or copy the file manually
       
      system cp data/arch/t1.ARZ data/arch/t2.ARZ
       
      -- Now we have new .ARZ, but old .frm (with 1 column)
       
      -- No indication that something has changed
      SHOW CREATE TABLE t2;
       
      FLUSH TABLES;
       
      -- First time we get ER_TABLE_DEF_CHANGED, it seems reasonable
      SHOW CREATE TABLE t2;
       
      -- .. but shouldn't it have been re-discovered?
      SHOW CREATE TABLE t2;
       
      -- and DROP doesn't work either
      DROP TABLE t2;

      revision-id: bar@mariadb.org-20130424142022-u4xhikvoqggze9b0
      revno: 3745
      branch-nick: 10.0

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              serg Sergei Golubchik
              Reporter:
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Git Integration

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