database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-12-24 11:21:21 +03:00
Code Activity

BUG#26138 - REPAIR TABLE with option USE_FRM erases all records in

Browse Source 
ARCHIVE table
ARCHIVE table was truncated by REPAIR TABLE ... USE_FRM statement.
The table handler returned its file name extensions in a wrong order.
REPAIR TABLE believed it has to use the meta file to create a new table
from it.

With the fixed order, REPAIR TABLE does now use the data file to create
a new table. So REPAIR TABLE ... USE_FRM works well with ARCHIVE engine
now.

This issue affects 5.0 only, since in 5.1 ARCHIVE engine stores meta
information and data in the same file.
This commit is contained in:
svoj@mysql.com/june.mysql.com
2007-03-30 13:00:21 +05:00
parent 75f0416532
commit 556de62f8d
6 changed files with 40 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
sql/handler.h
View File

@@ -780,6 +780,17 @@ public:
virtual void free_foreign_key_create_info(char* str) {}
/* The following can be called without an open handler */
virtual const char *table_type() const =0;
/*
If frm_error() is called then we will use this to find out what file
extentions exist for the storage engine. This is also used by the default
rename_table and delete_table method in handler.cc.
For engines that have two file name extentions (separate meta/index file
and data file), the order of elements is relevant. First element of engine
file name extentions array should be meta/index file extention. Second
element - data file extention. This order is assumed by
prepare_for_repair() when REPAIR TABLE ... USE_FRM is issued.
*/
virtual const char **bas_ext() const =0;
virtual ulong table_flags(void) const =0;
virtual ulong index_flags(uint idx, uint part, bool all_parts) const =0;