- 13 Feb, 2008 1 commit
-
-
kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.1-opt
-
- 12 Feb, 2008 5 commits
-
-
kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.1-opt
-
kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt
-
ssh://bk-internal.mysql.com//home/bk/mysql-5.1-optkaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.1-opt
-
kaa@mbp. authored
into mbp.:/Users/kaa/src/opt/bug33389/my51-bug25162
-
kaa@mbp. authored
or trigger crashes server Under some circumstances a combination of VIEWs, subselects with outer references and PS/SP/triggers could lead to use of uninitialized memory and server crash as a result. Fixed by changing the code in Item_field::fix_fields() so that in cases when the field is a VIEW reference, we first check whether the field is also an outer reference, and mark it appropriately before returning.
-
- 11 Feb, 2008 2 commits
-
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/21567/51-21567
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/21567/50-21567
-
- 10 Feb, 2008 9 commits
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/33796/my51-33796
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/33796/my50-33796
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/33796/my51-33796
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/33796/my50-33796
-
Field data for a query was stored to the stmt->alloc that is emptied with mysql_stmt_close statement only. That means a lot of memory can be occupied without a reason if used doesn't call mysql_stmt_close often.
-
into mysql.com:/home/tnurnberg/21567/51-21567
-
into mysql.com:/home/tnurnberg/21567/50-21567
-
ssh://bk-internal.mysql.com//home/bk/mysql-5.1-optkaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.1-opt
-
into blasphemy.intern.azundris.com:/home/tnurnberg/21567/51-21567
-
- 08 Feb, 2008 2 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
SET column storing procedure has been modified to be 64bit-clean.
-
- 07 Feb, 2008 7 commits
-
-
sergefp@pslp.mylan authored
into mysql.com:/home/psergey/mysql-5.0-bug27732
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
Minor post-fix for bug#34223.
-
sergefp@mysql.com authored
The bug was that handler::clone/handler::ha_open() call caused allocation of cloned_copy->ref on the handler->table->mem_root. The allocated memory could not be reclaimed until the table is flushed, so it was possible to exhaust memory by repeatedly running index_merge queries without doing table flushes. The fix: - make handler::clone() allocate new_handler->ref on the passed mem_root - make handler::ha_open() not allocate this->ref if it has already been allocated There is no testcase as it is not possible to check small leaks from testsuite.
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
Minor post-fix for bug#30059.
-
gshchepa/uchum@host.loc authored
and my_innodb_commit_concurrency global variables. Type of the my_innodb_autoextend_increment and the my_innodb_commit_concurrency variables has been changed to GET_ULONG.
-
- 06 Feb, 2008 1 commit
-
-
gshchepa/uchum@host.loc authored
Server handles truncation for assignment of too-long values into CHAR/VARCHAR/TEXT columns in a different ways when the truncated characters are spaces: 1. CHAR(N) columns silently ignore end-space truncation; 2. TEXT columns post a truncation warning/error in the non-strict/strict mode. 3. VARCHAR columns always post a truncation note in any mode. Space truncation processing has been synchronised over CHAR/VARCHAR/TEXT columns: current behavior of VARCHAR columns has been propagated as standard. Binary-encoded string/BLOB columns are not affected.
-
- 05 Feb, 2008 1 commit
-
-
Don't block SIGINT (Control-C) when --gdb is passed to mysqld. Was broken at least on OS X. (kudos to Mattias Jonsson)
-
- 01 Feb, 2008 4 commits
-
-
kaa@mbp.local authored
into mbp.local:/Users/kaa/src/opt/mysql-5.1-opt
-
kaa@mbp.local authored
into mbp.local:/Users/kaa/src/opt/mysql-5.0-opt
-
kaa@mbp.local authored
into mbp.local:/Users/kaa/src/opt/bug25162/my51-bug25162
-
kaa@mbp.local authored
on table creates The problem was in incompatible syntax for key definition in CREATE TABLE. 5.0 supports only the following syntax for key definition (see "CREATE TABLE syntax" in the manual): {INDEX|KEY} [index_name] [index_type] (index_col_name,...) While 5.1 parser supports the above syntax, the "preferred" syntax was changed to: {INDEX|KEY} [index_name] (index_col_name,...) [index_type] The above syntax is used in 5.1 for the SHOW CREATE TABLE output, which led to dumps generated by 5.1 being incompatible with 5.0. Fixed by changing the parser in 5.0 to support both 5.0 and 5.1 syntax for key definition.
-
- 31 Jan, 2008 3 commits
-
-
evgen@moonbone.local authored
Simple subselects are pulled into upper selects. This operation substitutes the pulled subselect for the first item from the select list of the subselect. If an alias is defined for a subselect it is inherited by the replacement item. As this is done after fix_fields phase this alias isn't showed if the replacement item is a stored function. This happens because the Item_func_sp::make_field function makes send field from its result_field and ignores the defined alias. Now when an alias is defined the Item_func_sp::make_field function sets it for the returned field.
-
holyfoot/hf@hfmain.mysql.com authored
into mysql.com:/home/hf/work/25426/my51-25426
-
holyfoot/hf@mysql.com/hfmain.(none) authored
Error message modified to be consistent with the manual.
-
- 30 Jan, 2008 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B31326-merge-5.1-opt
-
- 27 Jan, 2008 1 commit
-
-
igor@olga.mysql.com authored
Two disjuncts containing equalities of the form key=const1 and key=const2 can be merged into one if const1 is equal to const2. To check it the common collation of the constants were used rather than the collation of the field key. For example when the default collation of the constants was cases insensitive while the collation of the field was case sensitive, then two or-ed equality predicates key='b' and key='B' incorrectly were merged into one f='b'. As a result ref access was used instead of range access and wrong result sets were returned in many cases. Fixed the problem by comparing constant in the or-ed predicate with collation of the key field.
-
- 25 Jan, 2008 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
require SQL_BIG_SELECTS=1 There was a previous test that leaves a non-default (small) max_join_size. Fixed by re-setting the max_join_size to default when the test is over.
-
- 24 Jan, 2008 1 commit
-
-
ssh://bk-internal.mysql.com//home/bk/mysql-5.1kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.1-opt
-
- 20 Jan, 2008 1 commit
-
-
kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.1-opt
-