- 11 Mar, 2008 1 commit
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/32801/my51-32801
-
- 10 Mar, 2008 4 commits
-
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/34749/51-34749
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/34749/51-34749
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/29645/51-29645
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/29645/51-29645
-
- 08 Mar, 2008 2 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/bug34889/my51
-
- 07 Mar, 2008 2 commits
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B34909-5.1-opt
-
gkodinov/kgeorge@magare.gmz authored
--master-data No error code was returned by mysqldump if it detects that binary logging is not enabled on the server. Fixed by returning error code.
-
- 05 Mar, 2008 1 commit
-
-
kaa@kaamos.(none) authored
sporadically Under some circumstances, the mysql_insert_id() value after SELECT ... INSERT could return a wrong value. This could happen when the last SELECT ... INSERT did not involve an AUTO_INCREMENT column, but the value of mysql_insert_id() was changed by some previous statements. Fixed by checking the value of thd->insert_id_used in select_insert::send_eof() and returning 0 for mysql_insert_id() if it is not set.
-
- 03 Mar, 2008 11 commits
-
-
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@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.1-opt
-
kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt
-
gluh@mysql.com/mgluh.(none) authored
-
kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/bug31781/my51
-
kaa@kaamos.(none) authored
with errno 17 my_create() did not perform any checks for the case when a file is successfully created by a call to open(), but the call to my_register_filename() later fails because the number of open files has exceeded the my_open_files limit. This can happen on platforms which do not have getrlimit(), and hence we do not know the real limit for open files. In such a case an error was returned to a caller although the file has actually been created. Since callers assume my_create() to return an error only when it failed to create a file, they did not perform any cleanups, leaving an 'orphaned' file on the file system. Fixed by adding a check for the above case to my_create() and ensuring the newly created file is deleted before returning an error. Creating a deterministic test case in the test suite is impossible, because the exact steps required to reproduce the above situation depend on the platform and/or environment (OS per-user limits, queries executed by previous tests, startup parameters). The patch was manually tested on Windows using examples posted in the bug report.
-
gluh@mysql.com/mgluh.(none) authored
-
gluh@mgluh.(none) authored
into mysql.com:/home/gluh/MySQL/mysql-5.1-opt
-
gluh@mysql.com/mgluh.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
wait_timeout test enabled
-
- 01 Mar, 2008 2 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.1-opt
-
- 29 Feb, 2008 13 commits
-
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
-
gshchepa/uchum@host.loc authored
and Item_direct_ref constructor calls. Order of ref->field_name and ref->table_name arguments is of Item_ref and Item_direct_ref in the fix_inner_refs function is inverted.
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
added new function test_if_data_home_dir() which checks that path does not contain mysql data home directory. Using of mysql data home directory in DATA DIRECTORY & INDEX DIRECTORY is disallowed.
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
- 28 Feb, 2008 4 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.1-opt
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
Assertion `0' failed If ROW item is a part of an expression that also has aggregate function calls (COUNT/SUM/AVG...), a "splitting" with an Item::split_sum_func2 function is applied to that ROW item. Current implementation of Item::split_sum_func2 replaces this Item_row with a newly created Item_aggregate_ref reference to it. Then the row cache tries to work with the Item_aggregate_ref object as with the Item_row object: row cache calls row-emulation methods such as cols and element_index. Item_aggregate_ref (like it's parent Item_ref) inherits dummy implementations of those methods from the hierarchy root Item, and call to them leads to failed assertions and wrong data output. Row-emulation virtual functions (cols, element_index, addr, check_cols, null_inside and bring_value) of Item_ref have been overloaded to forward calls to an underlying item reference.
-
gkodinov/kgeorge@magare.gmz authored
-