mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-21 22:34:18 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/r/repair.result

186 lines
7 KiB
Text
Raw Normal View History

protected close_cached_table() call in REPAIR ... USE_FRM with a mutex test for REPAIR ... USE_FRM added
2002-09-01 18:17:33 +00:00
drop table if exists t1;
create table t1 SELECT 1,"table 1";
repair table t1 use_frm;
Table Op Msg_type Msg_text
test.t1 repair warning Number of rows changed from 0 to 1
test.t1 repair status OK
WorkLog#1323 Deprecate the use of TYPE=... Preferred syntax is ENGINE=
2003-12-10 04:31:42 +00:00
alter table t1 ENGINE=HEAP;
Fixed problem when comparing a key for a multi-byte-character set. (bug 152) Use 0x.... as strings if 'new' mode. (bug 152) Don't report -max on windows when InnoDB is enabled. (bug 332) Reset current_linfo; This could cause a hang when doing PURGE LOGS. Fix for row numbers in EXPLAIN (bug 322) Fix that USE_FRM works for all table types (bug 97)
2003-04-27 22:12:08 +03:00
repair table t1 use_frm;
Table Op Msg_type Msg_text
Fix to handle unsigned data in prepared statements (Bug #3447) Fixed security problem that password was temporarly reset when someone changed GRANT for a user. (Bug #3404) Fixed problem with PROCEDURE analyse() and impossible WHERE (Bug #2238) Don't auto-repair tables in mysqlcheck if table type doesn't support 'check' command.
2004-05-04 15:02:38 +03:00
test.t1 repair note The storage engine for the table doesn't support repair
Fixed problem when comparing a key for a multi-byte-character set. (bug 152) Use 0x.... as strings if 'new' mode. (bug 152) Don't report -max on windows when InnoDB is enabled. (bug 332) Reset current_linfo; This could cause a hang when doing PURGE LOGS. Fix for row numbers in EXPLAIN (bug 322) Fix that USE_FRM works for all table types (bug 97)
2003-04-27 22:12:08 +03:00
drop table t1;
Fix for #3067 (REPAIR TABLE reenables disabled keys)
2004-03-22 21:34:36 +04:00
create table t1(id int PRIMARY KEY, st varchar(10), KEY st_key(st));
insert into t1 values(1, "One");
alter table t1 disable keys;
show keys from t1;
Patch for WL#3736: Extended Table, Column and Index Comments. The task is to (a) add a comment on indexes and (b) increase the maximum length of column, table and the new index comments. The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).
2010-02-20 13:07:32 +03:00
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
t1 0 PRIMARY 1 id A 1 NULL NULL BTREE
t1 1 st_key 1 st A NULL NULL NULL YES BTREE disabled
Fix for #3067 (REPAIR TABLE reenables disabled keys)
2004-03-22 21:34:36 +04:00
repair table t1 extended;
Table Op Msg_type Msg_text
test.t1 repair status OK
show keys from t1;
Patch for WL#3736: Extended Table, Column and Index Comments. The task is to (a) add a comment on indexes and (b) increase the maximum length of column, table and the new index comments. The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).
2010-02-20 13:07:32 +03:00
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
t1 0 PRIMARY 1 id A 1 NULL NULL BTREE
t1 1 st_key 1 st A NULL NULL NULL YES BTREE disabled
Fix for #3067 (REPAIR TABLE reenables disabled keys)
2004-03-22 21:34:36 +04:00
drop table t1;
test case added
2003-05-03 15:21:39 +02:00
repair table t1 use_frm;
Table Op Msg_type Msg_text
BUG#26976 - Missing table in merge not noted in related error msg + SHOW CREATE TABLE fails Underlying table names, that merge engine fails to open were not reported. With this fix CHECK TABLE issued against merge table reports all underlying table names that it fails to open. Other statements are unaffected, that is underlying table names are not included into error message. This fix doesn't solve SHOW CREATE TABLE issue.
2007-06-06 04:42:41 +05:00
test.t1 repair Error Table 'test.t1' doesn't exist
Recommit for merging and pushing
2009-02-27 16:11:15 +02:00
test.t1 repair status Operation failed
WorkLog#1323 Deprecate the use of TYPE=... Preferred syntax is ENGINE=
2003-12-10 04:31:42 +00:00
create table t1 engine=myisam SELECT 1,"table 1";
Fixed problems noticed with last build
2004-04-09 07:12:41 +03:00
flush tables;
post-review fixes HA_EXTRA_WRITE_CACHE now part of start_bulk_insert() test cleanups
2004-04-07 16:04:28 +02:00
repair table t1;
Table Op Msg_type Msg_text
BUG#26976 - Missing table in merge not noted in related error msg + SHOW CREATE TABLE fails Underlying table names, that merge engine fails to open were not reported. With this fix CHECK TABLE issued against merge table reports all underlying table names that it fails to open. Other statements are unaffected, that is underlying table names are not included into error message. This fix doesn't solve SHOW CREATE TABLE issue.
2007-06-06 04:42:41 +05:00
test.t1 repair Error Incorrect file format 't1'
test.t1 repair error Corrupt
post-review fixes HA_EXTRA_WRITE_CACHE now part of start_bulk_insert() test cleanups
2004-04-07 16:04:28 +02:00
repair table t1 use_frm;
Table Op Msg_type Msg_text
test.t1 repair warning Number of rows changed from 0 to 1
test.t1 repair status OK
drop table t1;
BUG#18874 - Setting myisam_repair_threads > 1, index cardinality always 1 Fixed by moving update_key_parts() down to be after write_index().
2006-08-14 17:05:02 +05:00
CREATE TABLE t1(a INT, KEY(a));
INSERT INTO t1 VALUES(1),(2),(3),(4),(5);
SET myisam_repair_threads=2;
REPAIR TABLE t1;
Table Op Msg_type Msg_text
test.t1 repair status OK
SHOW INDEX FROM t1;
Patch for WL#3736: Extended Table, Column and Index Comments. The task is to (a) add a comment on indexes and (b) increase the maximum length of column, table and the new index comments. The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).
2010-02-20 13:07:32 +03:00
Table Non_unique Key_name Seq_in_index Column_name Collation Cardinality Sub_part Packed Null Index_type Comment Index_comment
t1 1 a 1 a A 5 NULL NULL YES BTREE
BUG#18874 - Setting myisam_repair_threads > 1, index cardinality always 1 Fixed by moving update_key_parts() down to be after write_index().
2006-08-14 17:05:02 +05:00
SET myisam_repair_threads=@@global.myisam_repair_threads;
DROP TABLE t1;
BUG#22562 - REPAIR TABLE .. USE_FRM causes server crash on Windows and server hangs on Linux If REPAIR TABLE ... USE_FRM is issued for table that is located in different than default database server crash could happen. In reopen_name_locked_table take database name from table_list (user specified or default database) instead of from thd (default database). Affects 4.1 only.
2006-10-11 20:34:20 +05:00
CREATE TABLE t1(a INT);
USE mysql;
REPAIR TABLE test.t1 USE_FRM;
Table Op Msg_type Msg_text
test.t1 repair status OK
USE test;
DROP TABLE t1;
BUG#23175 - MYISAM crash/repair failed during repair Repair table could crash a server if there is not sufficient memory (myisam_sort_buffer_size) to operate. Affects not only repair, but also all statements that use create index by sort: repair by sort, parallel repair, bulk insert. Return an error if there is not sufficient memory to store at least one key per BUFFPEK. Also fixed memory leak if thr_find_all_keys returns an error.
2006-10-18 17:57:29 +05:00
CREATE TABLE t1(a CHAR(255), KEY(a));
SET myisam_sort_buffer_size=4096;
INSERT INTO t1 VALUES
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0');
After merge fix.
2006-10-19 18:48:37 +05:00
Warnings:
Fix new error message list in v5.
2007-05-07 12:38:43 -04:00
Error 1034 myisam_sort_buffer_size is too small
After merge fix.
2006-10-19 18:48:37 +05:00
Error 1034 Number of rows changed from 0 to 157
BUG#23175 - MYISAM crash/repair failed during repair Repair table could crash a server if there is not sufficient memory (myisam_sort_buffer_size) to operate. Affects not only repair, but also all statements that use create index by sort: repair by sort, parallel repair, bulk insert. Return an error if there is not sufficient memory to store at least one key per BUFFPEK. Also fixed memory leak if thr_find_all_keys returns an error.
2006-10-18 17:57:29 +05:00
SET myisam_repair_threads=2;
REPAIR TABLE t1;
Table Op Msg_type Msg_text
Bug #27976: Misleading error message, 'Sort buffer to small' The message is gramatically wrong, and factually wrong. Change it to refer to the myisam_sort_buffer_size variable and change "to" to "too".
2007-05-04 17:38:29 -04:00
test.t1 repair error myisam_sort_buffer_size is too small
BUG#23175 - MYISAM crash/repair failed during repair Repair table could crash a server if there is not sufficient memory (myisam_sort_buffer_size) to operate. Affects not only repair, but also all statements that use create index by sort: repair by sort, parallel repair, bulk insert. Return an error if there is not sufficient memory to store at least one key per BUFFPEK. Also fixed memory leak if thr_find_all_keys returns an error.
2006-10-18 17:57:29 +05:00
test.t1 repair warning Number of rows changed from 0 to 157
test.t1 repair status OK
SET myisam_repair_threads=@@global.myisam_repair_threads;
SET myisam_sort_buffer_size=@@global.myisam_sort_buffer_size;
DROP TABLE t1;
Fix for bug #31174: "Repair" command on MyISAM crashes with small myisam_sort_buffer_size. An incorrect length of the sort buffer was used when calculating the maximum number of keys. When myisam_sort_buffer_size is small enough, this could result in the number of keys < number of BUFFPEK structures which in turn led to use of uninitialized BUFFPEKs. Fixed by correcting the buffer length calculation.
2007-10-11 14:28:12 +04:00
CREATE TABLE t1(a CHAR(255), KEY(a));
Fixed the test case for bug #31174 to not fail on 64-bit platforms.
2007-10-17 10:29:51 +04:00
SET myisam_sort_buffer_size=4496;
Fix for bug #31174: "Repair" command on MyISAM crashes with small myisam_sort_buffer_size. An incorrect length of the sort buffer was used when calculating the maximum number of keys. When myisam_sort_buffer_size is small enough, this could result in the number of keys < number of BUFFPEK structures which in turn led to use of uninitialized BUFFPEKs. Fixed by correcting the buffer length calculation.
2007-10-11 14:28:12 +04:00
INSERT INTO t1 VALUES
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),('0'),
('0'),('0'),('0'),('0'),('0'),('0'),('0');
SET myisam_repair_threads=2;
REPAIR TABLE t1;
Table Op Msg_type Msg_text
test.t1 repair status OK
SET myisam_repair_threads=@@global.myisam_repair_threads;
SET myisam_sort_buffer_size=@@global.myisam_sort_buffer_size;
DROP TABLE t1;
End of 4.1 tests
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.
2008-05-12 21:01:13 +05:00
# Test with a saved table from 4.1
SHOW TABLE STATUS LIKE 't1';
Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment
t1 MyISAM 9 Fixed 2 5 10 21474836479 1024 0 NULL # # NULL latin1_swedish_ci NULL
SELECT * FROM t1;
id
1
2
# Run CHECK TABLE, it should indicate table need a REPAIR TABLE
CHECK TABLE t1 FOR UPGRADE;
Table Op Msg_type Msg_text
Bug #42563: Message tells me to repair table though Storage Engine doesn't allow me to. In case of incompatible changes between old and new table versions, the mysqlcheck program prints error messages like this: error: Table upgrade required. Please do "REPAIR TABLE `table_name`" to fix it! However, InnoDB doesn't support REPAIR TABLE query, so the message is confusing. Error message text has been changed to: Table upgrade required. Please do "REPAIR TABLE `table_name`" or dump/reload to fix it!"
2009-04-14 19:19:15 +05:00
test.t1 check error Table upgrade required. Please do "REPAIR TABLE `t1`" or dump/reload to fix it!
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.
2008-05-12 21:01:13 +05:00
# REPAIR old table USE_FRM should fail
REPAIR TABLE t1 USE_FRM;
Table Op Msg_type Msg_text
fix typo This change was committed to the 5.1.25 release clone, but never made it to the mysql-5.1 BK tree. I'm committing it to mysql-5.1 bzr now.
2008-06-17 19:05:56 -06:00
t1 repair error Failed repairing incompatible .frm file
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.
2008-05-12 21:01:13 +05:00
# Run REPAIR TABLE to upgrade .frm file
REPAIR TABLE t1;
Table Op Msg_type Msg_text
test.t1 repair status OK
SHOW TABLE STATUS LIKE 't1';
Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment
t1 MyISAM 10 Fixed 2 7 14 1970324836974591 1024 0 NULL # # NULL latin1_swedish_ci NULL
SELECT * FROM t1;
id
1
2
REPAIR TABLE t1 USE_FRM;
Table Op Msg_type Msg_text
test.t1 repair warning Number of rows changed from 0 to 2
test.t1 repair status OK
SELECT * FROM t1;
id
1
2
DROP TABLE t1;
After merge fix.
2006-10-19 20:29:12 +05:00
DROP TABLE IF EXISTS tt1;
CREATE TEMPORARY TABLE tt1 (c1 INT);
REPAIR TABLE tt1 USE_FRM;
Table Op Msg_type Msg_text
tt1 repair error Cannot repair temporary table from .frm file
DROP TABLE tt1;
Backport of revno: 3702 Bug #48248 assert in MDL_ticket::upgrade_shared_lock_to_exclusive The assert would happen if REPAIR TABLE was used on a table already locked by LOCK TABLES READ. REPAIR mistakenly tried to upgrade the read-lock to exclusive, thereby triggering the assert. The cause of the problem was that REPAIR TABLE ignored errors from opening and locking tables. This is by design, as REPAIR can be used to broken tables that cannot be opened. However, repair also ignored logical errors such as the inability to exclusivly lock a table due to conflicting LOCK TABLES. This patch fixes the problem by not ignoring errors from opening and locking tables if inside LOCK TABLES mode. In LOCK TABLES we already know that the table can be opened, so that the failure to open must be a logical error. Test added to repair.test.
2009-12-09 14:03:37 +01:00
#
# Bug #48248 assert in MDL_ticket::upgrade_shared_lock_to_exclusive
#
DROP TABLE IF EXISTS t1;
CREATE TABLE t1(a INT);
LOCK TABLES t1 READ;
REPAIR TABLE t1;
Table Op Msg_type Msg_text
test.t1 repair Error Table 't1' was locked with a READ lock and can't be updated
test.t1 repair status Operation failed
UNLOCK TABLES;
DROP TABLE t1;
Fix for bug #50784 "MDL: Assertion `m_tickets.is_empty() || m_tickets.front() == m_trans_sentinel'". Debug build of server crashed due to assert failure in MDL subsystem when one tried to execute multi-table REPAIR or OPTIMIZE in autocommit=0 mode. The assert failure occured when multi-table REPAIR or OPTIMIZE started processing of second table from its table list and tried to acquire upgradable metadata lock on this table. The cause of the assert failure were MDL locks left over from processing of previous table. It turned out that in autocommit=0 mode close_thread_tables() which happens at the end of table processing doesn't release metadata locks. This fix solves problem by releasing locks explicitly using MDL_context::release_trans_locks() call.
2010-02-03 08:32:38 +03:00
#
# Test for bug #50784 "MDL: Assertion `m_tickets.is_empty() ||
# m_tickets.front() == m_trans_sentinel'"
#
drop tables if exists t1, t2;
create table t1 (i int);
create table t2 (j int);
set @@autocommit= 0;
repair table t1, t2;
Table Op Msg_type Msg_text
test.t1 repair status OK
test.t2 repair status OK
set @@autocommit= default;
drop tables t1, t2;
Reference in a new issue Copy permalink