From 6b7fea5f2b19ad04322026ffef74342d18412167 Mon Sep 17 00:00:00 2001 From: "istruewing@chilla.local" <> Date: Wed, 14 Mar 2007 16:27:37 +0100 Subject: [PATCH 1/4] Bug#25289 - repair table causes "my_seek.c:56: my_seek: Assertion `fd != -1' failed" In difficult optimize/repair situations the server could crash. Under some circumstances the server retries an optimize/repair with more elaborate options. But it did not check if the first attempt failed so badly that a second one must not be tried. This could happen when a new data file has been created but it was not possible to open it. In this case the repair leaves behind a table with closed data file. This must not be used for another repair attempt. We do now detect the closed data file and do not try another repair attempt in this situation. No test case. The required table corruption can not be repeated easily. There is a test program attached to bug 25433. --- sql/ha_myisam.cc | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/sql/ha_myisam.cc b/sql/ha_myisam.cc index 2cec03a51db..42be008de9e 100644 --- a/sql/ha_myisam.cc +++ b/sql/ha_myisam.cc @@ -867,6 +867,22 @@ int ha_myisam::repair(THD *thd, MI_CHECK ¶m, bool optimize) ha_rows rows= file->state->records; DBUG_ENTER("ha_myisam::repair"); + /* + Normally this method is entered with a properly opened table. If the + repair fails, it can be repeated with more elaborate options. Under + special circumstances it can happen that a repair fails so that it + closed the data file and cannot re-open it. In this case file->dfile + is set to -1. We must not try another repair without an open data + file. (Bug #25289) + */ + if (file->dfile == -1) + { + sql_print_information("Retrying repair of: '%s' failed. " + "Please try REPAIR EXTENDED or myisamchk", + table->path); + DBUG_RETURN(HA_ADMIN_FAILED); + } + param.db_name = table->table_cache_key; param.table_name = table->table_name; param.tmpfile_createflag = O_RDWR | O_TRUNC; From 344f33bb89d60f83e7ec7fdc2275f88dc9468523 Mon Sep 17 00:00:00 2001 From: "istruewing@chilla.local" <> Date: Mon, 19 Mar 2007 15:56:53 +0100 Subject: [PATCH 2/4] Bug#26996 - Update of a Field in a Memory Table ends with wrong result Using a MEMORY table BTREE index for scanning for updatable rows could lead to an infinite loop. Everytime a key was inserted into a btree index, the position in the index scan was cleared. The search started from the beginning and found the same key again. Now we do not clear the position on key insert an more. --- heap/hp_write.c | 1 - mysql-test/r/heap_btree.result | 15 +++++++++++++++ mysql-test/t/heap_btree.test | 14 ++++++++++++++ 3 files changed, 29 insertions(+), 1 deletion(-) diff --git a/heap/hp_write.c b/heap/hp_write.c index 841dda6264e..59dfca31fd9 100644 --- a/heap/hp_write.c +++ b/heap/hp_write.c @@ -106,7 +106,6 @@ int hp_rb_write_key(HP_INFO *info, HP_KEYDEF *keyinfo, const byte *record, heap_rb_param custom_arg; uint old_allocated; - info->last_pos= NULL; /* For heap_rnext/heap_rprev */ custom_arg.keyseg= keyinfo->seg; custom_arg.key_length= hp_rb_make_key(keyinfo, info->recbuf, record, recpos); if (keyinfo->flag & HA_NOSAME) diff --git a/mysql-test/r/heap_btree.result b/mysql-test/r/heap_btree.result index e6492e90b80..1a0666514be 100644 --- a/mysql-test/r/heap_btree.result +++ b/mysql-test/r/heap_btree.result @@ -280,4 +280,19 @@ a 1 1 drop table t1; +CREATE TABLE t1 ( +c1 CHAR(3), +c2 INTEGER, +KEY USING BTREE(c1), +KEY USING BTREE(c2) +) ENGINE= MEMORY; +INSERT INTO t1 VALUES ('ABC',0), ('A',0), ('B',0), ('C',0); +UPDATE t1 SET c2= c2 + 1 WHERE c1 = 'A'; +SELECT * FROM t1; +c1 c2 +ABC 0 +A 1 +B 0 +C 0 +DROP TABLE t1; End of 4.1 tests diff --git a/mysql-test/t/heap_btree.test b/mysql-test/t/heap_btree.test index 9aa820becd9..63baa968981 100644 --- a/mysql-test/t/heap_btree.test +++ b/mysql-test/t/heap_btree.test @@ -182,4 +182,18 @@ delete from t1 where a >= 2; select a from t1 order by a; drop table t1; +# +# Bug#26996 - Update of a Field in a Memory Table ends with wrong result +# +CREATE TABLE t1 ( + c1 CHAR(3), + c2 INTEGER, + KEY USING BTREE(c1), + KEY USING BTREE(c2) +) ENGINE= MEMORY; +INSERT INTO t1 VALUES ('ABC',0), ('A',0), ('B',0), ('C',0); +UPDATE t1 SET c2= c2 + 1 WHERE c1 = 'A'; +SELECT * FROM t1; +DROP TABLE t1; + --echo End of 4.1 tests From 8934e4f3cc2bdd6c4a24edd0cc6c96ee2325b0dc Mon Sep 17 00:00:00 2001 From: "istruewing@chilla.local" <> Date: Tue, 27 Mar 2007 10:49:48 +0200 Subject: [PATCH 3/4] Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Keys for BTREE indexes on ENUM and SET columns of MEMORY tables with character set UTF8 were computed incorrectly. Many different column values got the same key value. Apart of possible performance problems, it made unique indexes of this type unusable because it rejected many different values as duplicates. The problem was that multibyte character detection was tried on the internal numeric column value. Many values were not identified as characters. Their key value became blank filled. Thanks to Alexander Barkov and Ramil Kalimullin for the patch, which sets the character set of ENUM and SET key segments to the pseudo binary character set. --- mysql-test/r/heap_btree.result | 12 ++++++++++++ mysql-test/t/heap_btree.test | 17 +++++++++++++++++ sql/ha_heap.cc | 5 ++++- 3 files changed, 33 insertions(+), 1 deletion(-) diff --git a/mysql-test/r/heap_btree.result b/mysql-test/r/heap_btree.result index e6492e90b80..512a8a52845 100644 --- a/mysql-test/r/heap_btree.result +++ b/mysql-test/r/heap_btree.result @@ -280,4 +280,16 @@ a 1 1 drop table t1; +CREATE TABLE t1 ( +c1 ENUM('1', '2'), +UNIQUE USING BTREE(c1) +) ENGINE= MEMORY DEFAULT CHARSET= utf8; +INSERT INTO t1 VALUES('1'), ('2'); +DROP TABLE t1; +CREATE TABLE t1 ( +c1 SET('1', '2'), +UNIQUE USING BTREE(c1) +) ENGINE= MEMORY DEFAULT CHARSET= utf8; +INSERT INTO t1 VALUES('1'), ('2'); +DROP TABLE t1; End of 4.1 tests diff --git a/mysql-test/t/heap_btree.test b/mysql-test/t/heap_btree.test index 9aa820becd9..eb4672473f6 100644 --- a/mysql-test/t/heap_btree.test +++ b/mysql-test/t/heap_btree.test @@ -182,4 +182,21 @@ delete from t1 where a >= 2; select a from t1 order by a; drop table t1; +# +# Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE +# causes incorrect duplicate entries +# +CREATE TABLE t1 ( + c1 ENUM('1', '2'), + UNIQUE USING BTREE(c1) +) ENGINE= MEMORY DEFAULT CHARSET= utf8; +INSERT INTO t1 VALUES('1'), ('2'); +DROP TABLE t1; +CREATE TABLE t1 ( + c1 SET('1', '2'), + UNIQUE USING BTREE(c1) +) ENGINE= MEMORY DEFAULT CHARSET= utf8; +INSERT INTO t1 VALUES('1'), ('2'); +DROP TABLE t1; + --echo End of 4.1 tests diff --git a/sql/ha_heap.cc b/sql/ha_heap.cc index 3e981087df7..dd3a84aaaee 100644 --- a/sql/ha_heap.cc +++ b/sql/ha_heap.cc @@ -549,7 +549,10 @@ int ha_heap::create(const char *name, TABLE *table_arg, seg->start= (uint) key_part->offset; seg->length= (uint) key_part->length; seg->flag = 0; - seg->charset= field->charset(); + if (field->flags & (ENUM_FLAG | SET_FLAG)) + seg->charset= &my_charset_bin; + else + seg->charset= field->charset(); if (field->null_ptr) { seg->null_bit= field->null_bit; From 01be61e30770f64b0095a6aaf9b55db2369f1da8 Mon Sep 17 00:00:00 2001 From: "istruewing@chilla.local" <> Date: Tue, 27 Mar 2007 12:39:31 +0200 Subject: [PATCH 4/4] Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries After merge fix --- mysql-test/t/heap_btree.test | 35 +++++++++++++++++------------------ 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/mysql-test/t/heap_btree.test b/mysql-test/t/heap_btree.test index 14b1779bd1a..d2891943a4e 100644 --- a/mysql-test/t/heap_btree.test +++ b/mysql-test/t/heap_btree.test @@ -182,6 +182,23 @@ delete from t1 where a >= 2; select a from t1 order by a; drop table t1; +# +# Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE +# causes incorrect duplicate entries +# +CREATE TABLE t1 ( + c1 ENUM('1', '2'), + UNIQUE USING BTREE(c1) +) ENGINE= MEMORY DEFAULT CHARSET= utf8; +INSERT INTO t1 VALUES('1'), ('2'); +DROP TABLE t1; +CREATE TABLE t1 ( + c1 SET('1', '2'), + UNIQUE USING BTREE(c1) +) ENGINE= MEMORY DEFAULT CHARSET= utf8; +INSERT INTO t1 VALUES('1'), ('2'); +DROP TABLE t1; + --echo End of 4.1 tests # @@ -204,22 +221,4 @@ CREATE TABLE t1 (a INT, UNIQUE USING BTREE(a)) ENGINE=MEMORY; INSERT INTO t1 VALUES(NULL),(NULL); DROP TABLE t1; -# -# Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE -# causes incorrect duplicate entries -# -CREATE TABLE t1 ( - c1 ENUM('1', '2'), - UNIQUE USING BTREE(c1) -) ENGINE= MEMORY DEFAULT CHARSET= utf8; -INSERT INTO t1 VALUES('1'), ('2'); -DROP TABLE t1; -CREATE TABLE t1 ( - c1 SET('1', '2'), - UNIQUE USING BTREE(c1) -) ENGINE= MEMORY DEFAULT CHARSET= utf8; -INSERT INTO t1 VALUES('1'), ('2'); -DROP TABLE t1; - ---echo End of 4.1 tests --echo End of 5.0 tests