[MDEV-4442] Definition of ARCHIVE table is not re-discovered after replacing ARZ file - Jira

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

relates to

MDEV-3808 Better table discovery

Closed

Activity

Ascending order - Click to sort in descending order

Elena Stepanova added a comment - 2013-04-26 16:37

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]>

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

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

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

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'

Elena Stepanova added a comment - 2013-04-26 16:37 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. ############################################# 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] > ########################################################## End of the part of archive.discover ########################################################## ########################################################## 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'

Sergei Golubchik added a comment - 2013-06-16 17:32

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.

Sergei Golubchik added a comment - 2013-06-16 17:32 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.

MariaDB Server

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

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration