From 3c89dd7966e727d7ded902b195d8f133de94b565 Mon Sep 17 00:00:00 2001 From: unknown 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: Bug#25289 - repair table causes "my_seek.c:56: my_seek: Assertion `fd != -1' failed" Added code to detect a closed data file. It could be closed by a preceeding repair attempt. We must not try another repair then. --- 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 db573e637c2ba66f214f7e1e2172ce9efeca0db0 Mon Sep 17 00:00:00 2001 From: unknown 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: Bug#26996 - Update of a Field in a Memory Table ends with wrong result Removed the index-scan-breaking nulling of last_pos. The comment behind this line ("For heap_rnext/heap_rprev") was misleading. It should have been "Breaks heap_rnext/heap_rprev". mysql-test/r/heap_btree.result: Bug#26996 - Update of a Field in a Memory Table ends with wrong result Added test result. mysql-test/t/heap_btree.test: Bug#26996 - Update of a Field in a Memory Table ends with wrong result Added test. --- 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 1fd0ba8909465f70c3b4e5d4dea4dc56b132896a Mon Sep 17 00:00:00 2001 From: unknown 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: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Added test result. mysql-test/t/heap_btree.test: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Added test. sql/ha_heap.cc: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Set key segment charset to my_charset_bin for ENUM and SET columns. --- 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 de3c37195691a19ac504dd60daf516219d59c503 Mon Sep 17 00:00:00 2001 From: unknown 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