summaryrefslogtreecommitdiff
path: root/mysql-test/std_data/bug36055.MYD
diff options
context:
space:
mode:
authorgshchepa/uchum@host.loc <>2008-05-12 21:01:13 +0500
committergshchepa/uchum@host.loc <>2008-05-12 21:01:13 +0500
commit1e7be565e20100b5be68fe0476b5276362b0de73 (patch)
treec199105fc93fb719a3a0fc021e64ed6662c0b00e /mysql-test/std_data/bug36055.MYD
parente9e6679381bf1b3c114302a338b66beee59e9bef (diff)
downloadmariadb-git-1e7be565e20100b5be68fe0476b5276362b0de73.tar.gz
Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables
The REPAIR TABLE ... USE_FRM query silently corrupts data of tables with old .FRM file version. The mysql_upgrade client program or the REPAIR TABLE query (without the USE_FRM clause) can't prevent this trouble, because in the common case they don't upgrade .FRM file to compatible structure. 1. Evaluation of the REPAIR TABLE ... USE_FRM query has been modified to reject such tables with the message: "Failed repairing incompatible .FRM file". 2. REPAIR TABLE query (without USE_FRM clause) evaluation has been modified to upgrade .FRM files to current version. 3. CHECK TABLE ... FOR UPGRADE query evaluation has been modified to return error status when .FRM file has incompatible version. 4. mysql_upgrade and mysqlcheck client programs call CHECK TABLE FOR UPGRADE and REPAIR TABLE queries, so their behaviors have been changed too to upgrade .FRM files with incompatible version numbers.
Diffstat (limited to 'mysql-test/std_data/bug36055.MYD')
-rw-r--r--mysql-test/std_data/bug36055.MYDbin0 -> 10 bytes
1 files changed, 0 insertions, 0 deletions
diff --git a/mysql-test/std_data/bug36055.MYD b/mysql-test/std_data/bug36055.MYD
new file mode 100644
index 00000000000..4932a077113
--- /dev/null
+++ b/mysql-test/std_data/bug36055.MYD
Binary files differ