- 29 Jul, 2006 1 commit
-
-
ingo/mydev@chilla.local authored
After merge fix
-
- 26 Jul, 2006 1 commit
-
-
ingo/mydev@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug20719
-
- 21 Jul, 2006 2 commits
-
-
ingo/mydev@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1
-
ingo/mydev@chilla.local authored
Fixed a possible problem with reading of dynamic records when a write cache is active. The cache must be flushed whenever a part of the file in the write cache is to be read. Added a read optimization to _mi_read_dynamic_record(). No test case. This was a hypothetical but existing problem.
-
- 09 Jul, 2006 1 commit
-
-
closing temp tables through end_thread had a flaw in binlog-off branch of close_temporary_tables where next table to close was reset via table->next for (table= thd->temporary_tables; table; table= table->next) which was wrong since the current table instance got destoyed at close_temporary(table, 1); The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.
-
- 04 Jul, 2006 1 commit
-
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-4.1-bug14400
-
- 29 Jun, 2006 1 commit
-
-
tomas@poseidon.ndb.mysql.com authored
-
- 28 Jun, 2006 1 commit
-
-
ingo@mysql.com authored
It was possible that fetching a record by an exact key value (including the record pointer) could return a record with a different key value. This happened only if a concurrent insert added a record with the searched key value after the fetching statement locked the table for read. The search succeded on the key value, but the record was rejected as it was past the file length that was remembered at start of the fetching statement. With other words it was rejected as being a concurrently inserted record. The action to recover from this problem was to fetch the record that is pointed at by the next key of the index. This was repeated until a record below the file length was found. I do now avoid this loop if an exact match was searched. If this match is beyond the file length, it is now treated as "key not found". There cannot be another key with the same record pointer.
-
- 27 Jun, 2006 3 commits
-
-
svoj@may.pils.ru authored
Produce a warning if DATA/INDEX DIRECTORY is specified in ALTER TABLE statement. Ignoring of these options is documented in the symbolic links section of the manual.
-
kroki@mysql.com authored
Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-4.1.clean
-
- 26 Jun, 2006 4 commits
-
-
kent@mysql.com authored
into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new
-
kent@mysql.com authored
For compatibility, don't use {..,..} in pattern matching make_binary_distribution.sh: Added .dylib and .sl as shared library extensions
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-4.1.clean
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-4.1.clean
-
- 23 Jun, 2006 1 commit
-
-
bar@mysql.com authored
An UNIQUE KEY consisting of NOT NULL columns was displayed as PRIMARY KEY in "DESC t1". According to the code, that was intentional behaviour for some reasons unknown to me. This code was written before bitkeeper time, so I cannot check who and why made this. After discussing on dev-public, a decision was made to remove this code
-
- 22 Jun, 2006 2 commits
-
-
kent@mysql.com authored
Disable the simplistic auto dependency scan for test/bench (bug#20078)
-
holyfoot@deer.(none) authored
The AsBinary function returns VARCHAR data type with binary collation. It can cause problem for clients that treat that kind of data as different from BLOB type. So now AsBinary returns BLOB.
-
- 21 Jun, 2006 6 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
This bug in Field_string::cmp resulted in a wrong comparison with keys in partial indexes over multi-byte character fields. Given field a is declared as a varchar(16) collate utf8_unicode_ci INDEX(a(4)) gives us an example of such an index. Wrong key comparisons could lead to wrong result sets if the selected query execution plan used a range scan by a partial index over a utf8 character field. This also caused wrong results in many other cases.
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
-
tomas@poseidon.ndb.mysql.com authored
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
-
svoj@may.pils.ru authored
functions in queries Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE) results in error 124 (wrong index) from storage engine. The problem was that optimizer use disabled index to optimize MAX()/MIN(). Normally it must skip disabled index and perform table scan. This patch skips disabled indexes for min/max optimization.
-
- 20 Jun, 2006 5 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
Added test case for bug#18759 Incorrect string to numeric conversion. select.test: Added test case for bug#18759 Incorrect string to numeric conversion. item_cmpfunc.cc: Cleanup after fix for bug#18360 removal
-
ramil@mysql.com authored
into mysql.com:/usr/home/ram/work/mysql-4.1
-
ramil@mysql.com authored
into mysql.com:/usr/home/ram/work/mysql-4.1
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
- 19 Jun, 2006 10 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
Reverted fix for bug#18360
-
holyfoot@deer.(none) authored
there was two problems about charsets in embedded server 1. mysys/charset.c - defined there default_charset_info variable is modified by both server and client code (particularly when --default-charset option is handled) In embedded server we get two codelines modifying one variable. I created separate default_client_charset_info for client code 2. mysql->charset and mysql->options.charset initialization isn't properly done for embedded server - necessary calls added
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/4.1/B9676
-
gkodinov@mysql.com authored
tables Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a temporary table to store the results of SELECT ... LIMIT .. and then uses that table as a source for INSERT. The problem is that in some cases it actually skips the LIMIT clause in doing that and materializes the whole SELECT result set regardless of the LIMIT. This fix is limiting the process of filling up the temp table with only that much rows that will be actually used by propagating the LIMIT value.
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG18036/mysql-4.1
-
svoj@may.pils.ru authored
Certain updates of table joined to self results in unexpected behavior. The problem was that record cache was mistakenly enabled for self-joined table updates. Normally record cache must be disabled for such updates. Fixed wrong condition in code that determines whether to use record cache for self-joined table updates. Only MyISAM tables were affected.
-
ramil@mysql.com authored
-
- 18 Jun, 2006 1 commit
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-