- 25 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0--team
-
- 15 Mar, 2007 4 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25289
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg25966-2
-
dlenev@mockturtle.local authored
TABLE ... WRITE". Memory and CPU hogging occured when connection which had to wait for table lock was serviced by thread which previously serviced connection that was killed (note that connections can reuse threads if thread cache is enabled). One possible scenario which exposed this problem was when thread which provided binlog dump to replication slave was implicitly/automatically killed when the same slave reconnected and started pulling data through different thread/connection. The problem also occured when one killed particular query in connection (using KILL QUERY) and later this connection had to wait for some table lock. This problem was caused by the fact that thread-specific mysys_var::abort variable, which indicates that waiting operations on mysys layer should be aborted (this includes waiting for table locks), was set by kill operation but was never reset back. So this value was "inherited" by the following statements or even other connections (which reused the same physical thread). Such discrepancy between this variable and THD::killed flag broke logic on SQL-layer and caused CPU and memory hogging. This patch tries to fix this problem by properly resetting this member. There is no test-case associated with this patch since it is hard to test for memory/CPU hogging conditions in our test-suite.
-
dlenev@mockturtle.local authored
TABLE ... WRITE". CPU hogging occured when connection which had to wait for table lock was serviced by thread which previously serviced connection that was killed (note that connections can reuse threads if thread cache is enabled). One possible scenario which exposed this problem was when thread which provided binlog dump to replication slave was implicitly/automatically killed when the same slave reconnected and started pulling data through different thread/connection. In 5.* versions memory hogging was added to CPU hogging. Moreover in those versions the problem also occured when one killed particular query in connection (using KILL QUERY) and later this connection had to wait for some table lock. This problem was caused by the fact that thread-specific mysys_var::abort variable, which indicates that waiting operations on mysys layer should be aborted (this includes waiting for table locks), was set by kill operation but was never reset back. So this value was "inherited" by the following statements or even other connections (which reused the same physical thread). Such discrepancy between this variable and THD::killed flag broke logic on SQL-layer and caused CPU and memory hogging. This patch tries to fix this problem by properly resetting this member. There is no test-case associated with this patch since it is hard to test for memory/CPU hogging conditions in our test-suite.
-
- 14 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
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.
-
- 13 Mar, 2007 6 commits
-
-
svoj@mysql.com/april.(none) authored
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
differences in tables Certain merge tables were wrongly reported as having incorrect definition: - Some fields that are 1 byte long (e.g. TINYINT, CHAR(1)), might be internally casted (in certain cases) to a different type on a storage engine layer. (affects 4.1 and up) - If tables in a merge (and a MERGE table itself) had short VARCHAR column (less than 4 bytes) and at least one (but not all) tables were ALTER'ed (even to an identical table: ALTER TABLE xxx ENGINE=yyy), table definitions went ouf of sync. (affects 4.1 only) This is fixed by relaxing a check for underlying conformance and setting field type to FIELD_TYPE_STRING in case varchar is shorter than 4 when a table is created.
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG26881/mysql-4.1-engines
-
- 10 Mar, 2007 6 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/25373-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
When the SUBSTRING() function was used over a LONGTEXT field the max_length of the SUBSTRING() result was wrongly calculated and set to 0. As the max_length parameter is used while tmp field creation it limits the length of the result field and leads to printing an empty string instead of the correct result. Now the Item_func_substr::fix_length_and_dec() function correctly calculates the max_length parameter.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/25373-bug-5.0-opt-mysql
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug25673
-
istruewing@blade08.mysql.com authored
into blade08.mysql.com:/data0/istruewing/autopush/mysql-5.0-bug25673
-
igor@olga.mysql.com authored
Crash happened because the function get_best_group_min_max detected joins with ROLLUP incorrectly.
-
- 09 Mar, 2007 12 commits
-
-
evgen@moonbone.local authored
away. Additional fix for bug#22331. Now Item_field prints its value in the case of the const field.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25673
-
istruewing@chilla.local authored
Fixed a compiler warning, deteced by pushbuild only.
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B26281-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B26281-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
Fixed boundry checks in the INSERT() function: were one off.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26661
-
igor@olga.mysql.com authored
construct references invalid name. Derived tables currently cannot use outer references. Thus there is no outer context for them. The 4.1 code takes this fact into account while the Item_field::fix_outer_field code of 5.0 lost the check that blocks any attempts to resolve names in outer context for derived tables.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
- 08 Mar, 2007 10 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25673
-
istruewing@chilla.local authored
After backport fix. Added forgotten DBUG_RETURNs, which was detected in 5.1 only.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/mrg/mysql-4.1-opt
-
evgen@moonbone.local authored
Postfix for bug#22331.
-
msvensson@pilot.blaudden authored
into pilot.blaudden:/home/msvensson/mysql/mysql-4.1-maint
-
msvensson@pilot.blaudden authored
into pilot.blaudden:/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@pilot.blaudden authored
into pilot.blaudden:/home/msvensson/mysql/mysql-5.0-maint
-
istruewing@chilla.local authored
After merge fix
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25673
-