CHECK TABLE persistently reports table corruption after removing Aria logs

[Elena Stepanova]

This is a sequel of bug #944422, now on

revision-id: <email address hidden>
date: 2012-03-28 13:58:14 +0300
build-date: 2012-03-29 04:40:31 +0400
revno: 3481

After the fix for bug #944422 the behavior changed: now with the same scenario, after Aria logs have been removed and server restarted, CHECK TABLE gives the message "Corrupt / Table is from another system and must be zerofilled or repaired to be usable on this system", as apparently designed.

However, I could not get rid of this message neither by running REPAIR TABLE on the running server, nor by running aria_chk --recover t.MAI.
REPAIR TABLE says
+--------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------+--------+----------+----------+
| test.t | repair | status | OK |
+--------+--------+----------+----------+

but further CHECK TABLE t again complains about corruption:
+--------+-------+----------+---------------------------------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+--------+-------+----------+---------------------------------------------------------------------------------------------+
| test.t | check | error | Table is from another system and must be zerofilled or repaired to be usable on this system |
| test.t | check | error | Corrupt |
+--------+-------+----------+---------------------------------------------------------------------------------------------+

aria_chk --recover says
- recovering (with keycache) Aria-table '/home/elenst/5.3.5-release/data/test/t.MAI'
Data records: 4
State updated

But the result is the same, CHECK TABLE still throws the message about corruption.
I could make it stop only by altering the table to another engine and then back.
It differs from the previous behavior when REPAIR TABLE would make the error message go away.
I didn't notice actual corruption though, the table still returns rows, I can insert into it, etc.

The scenario to reproduce is pretty much the same as in bug #944422:

- start server (no specific server parameters required);
- run
mysql -uroot -e "DROP DATABASE IF EXISTS db; CREATE DATABASE db; USE db; \
CREATE TABLE t ( i INT ) ENGINE=Aria; BEGIN; INSERT INTO t VALUES (1),(2); COMMIT; \
BEGIN; INSERT INTO t VALUES (1),(2); COMMIT;"
(adjust connection parameter such as port or socket, if needed)

- stop server, e.g. using mysqladmin -uroot shutdown
- remove aria_log* files from the datadir;
- start server on the same datadir;

- run
mysql -uroot -e "CHECK TABLE db.t"
(it says "Table is from another system and must be zerofilled or repaired to be usable on this system / Corrupt")

- run
mysql -uroot -e "REPAIR TABLE db.t"
( it says status OK)

- again, run
mysql -uroot -e "CHECK TABLE db.t"
(it still says "Table is from another system and must be zerofilled or repaired to be usable on this system / Corrupt")

- stop server

- run aria_chk --recover test/t.MAI
(it says "State updated")

- start server

- run
mysql -uroot -e "CHECK TABLE db.t"
(still reports corruption)

[Michael Widenius (monty)]

I had forgot to remove the 'moved' mark from repaired tables. This is now fixed in MariaDB 5.1 and above