[MDEV-4442] Definition of ARCHIVE table is not re-discovered after replacing ARZ file Created: 2013-04-26  Updated: 2013-06-16  Resolved: 2013-06-16

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.2
Fix Version/s: 10.0.4

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-3808 Better table discovery Closed

 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



 Comments   
Comment by Elena Stepanova [ 2013-04-26 ]

Following IRC comments, I've compared what's done in archive.discover test with what the one in this report does.
To eliminate the weird dependence on MySQL client vs MTR, I executed both in the client, and made them as similar as possible (converted mine into alter table, etc.).
It seems that the result depends on what exact table alteration has been done.
In the test here, a number of column changes, and it causes the problem.
In archive.discover, a default value on a column changes, and it does not seem to cause the problem, it gets re-discovered all right.
The output of both experiments is below.

#############################################

    1. A part of archive.discover executed via MySQL client:
      #############################################

MariaDB [test]> create table t1 (a int) engine=archive;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> system cp data/test/t1.ARZ data/
MariaDB [test]> alter table t1 modify column a int default '5';
Query OK, 0 rows affected (0.44 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [test]> insert into t1 values (1);
Query OK, 1 row affected (0.00 sec)

MariaDB [test]> show create table t1;
--------------------------------------------------------------------------------------------+

Table Create Table

--------------------------------------------------------------------------------------------+

t1 CREATE TABLE `t1` (
`a` int(11) DEFAULT '5'
) ENGINE=ARCHIVE DEFAULT CHARSET=latin1

--------------------------------------------------------------------------------------------+
1 row in set (0.08 sec)

MariaDB [test]> system cp data/t1.ARZ data/test/
MariaDB [test]> show create table t1;
--------------------------------------------------------------------------------------------+

Table Create Table

--------------------------------------------------------------------------------------------+

t1 CREATE TABLE `t1` (
`a` int(11) DEFAULT '5'
) ENGINE=ARCHIVE DEFAULT CHARSET=latin1

--------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [test]> flush tables;
Query OK, 0 rows affected (0.01 sec)

MariaDB [test]> show create table t1;
---------------------------------------------------------------------------------------------+

Table Create Table

---------------------------------------------------------------------------------------------+

t1 CREATE TABLE `t1` (
`a` int(11) DEFAULT NULL
) ENGINE=ARCHIVE DEFAULT CHARSET=latin1

---------------------------------------------------------------------------------------------+
1 row in set (0.21 sec)

MariaDB [test]>

##########################################################

  1. End of the part of archive.discover
    ##########################################################

##########################################################

  1. A test based on this report
    ##########################################################

MariaDB [test]> create table t1 (a int, b int) engine=archive;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> system cp data/test/t1.ARZ data/
MariaDB [test]> alter table t1 drop column b;
Query OK, 0 rows affected (0.44 sec)
Records: 0 Duplicates: 0 Warnings: 0

MariaDB [test]> insert into t1 values (1);
Query OK, 1 row affected (0.01 sec)

MariaDB [test]> show create table t1;
---------------------------------------------------------------------------------------------+

Table Create Table

---------------------------------------------------------------------------------------------+

t1 CREATE TABLE `t1` (
`a` int(11) DEFAULT NULL
) ENGINE=ARCHIVE DEFAULT CHARSET=latin1

---------------------------------------------------------------------------------------------+
1 row in set (0.11 sec)

MariaDB [test]> system cp data/t1.ARZ data/test/
MariaDB [test]> show create table t1;
---------------------------------------------------------------------------------------------+

Table Create Table

---------------------------------------------------------------------------------------------+

t1 CREATE TABLE `t1` (
`a` int(11) DEFAULT NULL
) ENGINE=ARCHIVE DEFAULT CHARSET=latin1

---------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

MariaDB [test]> flush tables;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> show create table t1;
ERROR 1412 (HY000): Table definition has changed, please retry transaction
MariaDB [test]> show create table t1;
ERROR 1033 (HY000): Incorrect information in file: './test/t1.frm'

Comment by Sergei Golubchik [ 2013-06-16 ]

It's not a bug. You copy t1.ARZ over t2.ARZ, while t2 table is still open. When later you close t2, it overwrites part of the new t2.ARZ. As a result you get a non-functional corrupted ARZ file.

If you execute FLUSH TABLES before copying files around, t2 will be discovered correctly.

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