- 05 Jul, 2006 4 commits
-
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-ateam
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-ateam
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-ateam
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-ateam
-
- 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
+ adopted signal to be as close as possible to 5.1...
-
- 28 Jun, 2006 3 commits
-
-
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.
-
ingo@mysql.com authored
A corrupt table with dynamic record format can crash the server when trying to select from it. I fixed the crash that resulted from the particular type of corruption that has been reported for this bug. No test case. To test it, one needs a table with a very special corruption. The bug report contains a file with such a table.
-
ingo@mysql.com authored
CHECK TABLE could complain about a fully intact spatial index. A wrong comparison operator was used for table checking. The result was that it checked for non-matching spatial keys. This succeeded if at least two different keys were present, but failed if only the matching key was present. I fixed the key comparison.
-
- 27 Jun, 2006 6 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
-
ingo@mysql.com authored
Very complex select statements can create temporary tables that are too big to be represented as a MyISAM table. This was not checked at table creation time, but only at open time. The result was an attempt to delete the "impossible" table. But if the server is built --with-raid, MyISAM tries to open the table before deleting the files. It needs to find out if the table uses the raid support and how many raid chunks there are. This is done with an open "for repair", which will almost always succeed. But in this case we have an "impossible" table. The open failed. Hence the files were not deleted. Also the error message was a bit unspecific. I turned an open error in this situation into the assumption of having no raid support on the table. Thus the normal data file is tried to be deleted. This may however leave existing raid chunks behind. I also added a check in mi_create() to prevent the creation of an "impossible" table. A more decriptive error message is given in this case. No test case. The required select statement is way too large for the test suite. I added a test script to the bug report.
-
tomas@poseidon.ndb.mysql.com authored
- correction of previous patch
-
tomas@poseidon.ndb.mysql.com authored
- make sure to allocate just enough pages in the fragments by using the actual row count from the backup, to avoid over allocation of pages to fragments, and thus avoid the bug
-
- 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 10 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.
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
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.
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
ramil@mysql.com authored
into mysql.com:/usr/home/ram/work/mysql-5.0
-
- 20 Jun, 2006 8 commits
-
-
evgen@moonbone.local authored
Additional fix for #16377 for bigendian platforms sql_select.cc, select.result, select.test: After merge fix
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
-
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
-
evgen@moonbone.local authored
-
elliot@mysql.com authored
into mysql.com:/home/emurphy/mysql-5.0-heikki
-
elliot@mysql.com authored
Fixes bug#17264, for alter table on win32 for successfull operation completion it is used TL_WRITE(=10) lock instead of TL_WRITE_ALLOW_READ(=6), however here in innodb handler TL_WRTIE is lifted to TL_WRITE_ALLOW_WRITE, which causes race condition when several clients do alter table simultaneously.
-