- 22 Feb, 2008 3 commits
-
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/autopush/B30604-5.0-opt
-
unknown authored
into mysql.com:/home/gluh/MySQL/mysql-5.0-opt
-
unknown authored
skip lock_type update for temporary tables mysql-test/r/tablelock.result: test result mysql-test/t/tablelock.test: test case sql/sql_base.cc: skip lock_type update for temporary tables
-
- 20 Feb, 2008 2 commits
-
-
unknown authored
into moonbone.local:/work/33266-bug-5.0-opt-mysql
-
unknown authored
The test case for the bug#31048 checks that there is no crash on stack overrun. But due to different stack sizes on different platforms it failed on some of them. The new test case check that a query with at least 4 level subquery nesting works without the stack overrun nesting and other levels of nesting doesn't cause a crash. mysql-test/t/subselect.test: Corrected test case for the bug#31048. mysql-test/r/subselect.result: Corrected test case for the bug#31048.
-
- 19 Feb, 2008 1 commit
-
-
unknown authored
and ps-protocol Finding a routine should be a transparent operation as far as the binary log is concerned. But it was influencing the binary log because of the TIMESTAMP column in the proc table. Fixed by preserving and restoring the time_zone usage flag when searching for a stored routine in the proc table. mysql-test/r/binlog_innodb.result: Bug #30604: test case mysql-test/r/ctype_cp932_binlog.result: Bug #30604: updated test results (a procedure call before that) mysql-test/t/binlog_innodb.test: Bug #30604: test case sql/sp.cc: Bug #30604: finding a routine should be a transparent operation as far as the binary log is concerned. Fixed by preserving and restoring the time_zone usage flag.
-
- 18 Feb, 2008 1 commit
-
-
unknown authored
into mysql.com:/home/hf/work/32942/my50-32942 sql/sql_select.cc: Auto merged mysql-test/r/select.result: merging mysql-test/t/select.test: merging
-
- 17 Feb, 2008 5 commits
-
-
ssh://bk-internal.mysql.com//home/bk/mysql-5.0-optunknown authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt sql/item.cc: Auto merged
-
unknown authored
Problem is not about intervals and doesn't actually cause 'full table scan'. We have an optimization for DISTINCT when we have 'DISTINCT field_from_first_join_table' we don't need to read all the rows from the JOIN-ed table if we found one conforming row. It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon that case in the evaluate_join_record() and that doesn't break the recordreading loop in sub_select(). Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case. mysql-test/r/select.result: Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan". test result mysql-test/t/select.test: Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan" test case sql/sql_select.cc: Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan" return NESTED_LOOP_NO_MORE_ROWS when we don't need to read rows from this table anymore
-
unknown authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt
-
unknown authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt mysql-test/r/variables.result: Auto merged mysql-test/t/variables.test: Auto merged sql/item.cc: Auto merged sql/item_cmpfunc.cc: Auto merged sql/sql_acl.cc: Auto merged sql/sql_select.cc: Auto merged sql/sql_yacc.yy: Auto merged mysql-test/r/sp.result: Manual merge. mysql-test/t/sp.test: Manual merge.
-
unknown authored
into kaamos.(none):/data/src/opt/mysql-4.1-opt
-
- 15 Feb, 2008 2 commits
-
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31887-5.0-opt sql/item.cc: Auto merged sql/mysql_priv.h: Auto merged
-
unknown authored
when executed in version 5 Zero fill is a field attribute only. So we can't always propagate constants for zerofill fields : the values and expression results don't have that flag. Fixed by converting the const value to a string and using that in const propagation when the context allows it. Disable const propagation for fields with ZEROFILL flag in all the other cases. mysql-test/r/compare.result: Bug #31887: test case mysql-test/t/compare.test: Bug #31887: test case sql/item.cc: Bug #31887: If the context allows conversion of an int constant to a zero-filled string constant put the string constant instead of the int constant when doing const propagation sql/mysql_priv.h: Bug #31887: a macro to get all the Field_num descendant fields.
-
- 14 Feb, 2008 1 commit
-
-
ssh://bk-internal.mysql.com//home/bk/mysql-5.0-optunknown authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt
-
- 13 Feb, 2008 3 commits
-
-
unknown authored
into host.loc:/home/uchum/work/5.0-opt
-
unknown authored
for wildcard values. The server ignored escape character before wildcards during the calculation of priority values for sorting of a privilege list. (Actually the server counted an escape character as an ordinary wildcard like % or _). I.e. the table name template with a wildcard character like 'tbl_1' had higher priority in a privilege list than concrete table name without wildcards like 'tbl\_1', and some privileges of 'tbl\_1' was hidden by privileges for 'tbl_1'. The get_sort function has been modified to ignore escaped wildcards as usual. mysql-test/r/grant3.result: Added test case for bug#31194. mysql-test/t/grant3.test: Added test case for bug#31194. sql/sql_acl.cc: Fixed bug#31194. The server used the wild_prefix escape character (usually \-character) like % and _ wildcards in the get_sort function for sorting weights calculation. The get_sort function has been modified to ignore escaped wildcards and alone escapes like in the wild_case_compare function.
-
unknown authored
type conversion. Instead of copying of whole character string from a temporary buffer, the server copied a short-living pointer to that string into a long-living structure. That has been fixed. mysql-test/r/select.result: Added test case for bug#33764. mysql-test/t/select.test: Added test case for bug#33764. sql/item_cmpfunc.cc: Fixed bug#33764. Copying of a pointer has been replaced with an optional copying of a whole array to a newly allocated memory space in case of a functional source item.
-
- 12 Feb, 2008 3 commits
-
-
unknown authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt sql/item.cc: Auto merged
-
unknown authored
into moonbone.local:/work/31590-bug-5.0-opt-mysql
-
unknown 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. mysql-test/r/view.result: Added a test case for bug #33389. mysql-test/t/view.test: Added a test case for bug #33389. sql/item.cc: In cases when in Item_field::fix_fields() from_field is a view reference, do not return too early, i.e. before marking the reference as an outer one when needed.
-
- 11 Feb, 2008 3 commits
- 10 Feb, 2008 4 commits
-
-
unknown authored
into mysql.com:/home/hf/work/33796/my50-33796
-
unknown authored
into mysql.com:/home/hf/work/33796/my50-33796 libmysql/libmysql.c: merging libmysqld/lib_sql.cc: merging
-
unknown authored
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. libmysql/libmysql.c: Bug #33796 Memory leak for prepared statements in embedded server. Clean up result->alloc even if there's no 'data' created libmysqld/lib_sql.cc: Bug #33796 Memory leak for prepared statements in embedded server. alloc 'fields' in the 'result.alloc' as the 'mem_root' is only cleaned with mysql_stmt_close'
-
unknown authored
into mysql.com:/home/tnurnberg/21567/50-21567 sql/mysqld.cc: Auto merged
-
- 08 Feb, 2008 5 commits
-
-
unknown authored
into dipika.(none):/opt/local/work/mysql-5.0-runtime
-
unknown authored
into host.loc:/home/uchum/work/5.0-opt
-
unknown authored
SET column storing procedure has been modified to be 64bit-clean. mysql-test/r/type_set.result: Added test case for bug#15409. mysql-test/t/type_set.test: Added test case for bug#15409. sql/field.cc: Fixed bug#15409. The Field_set::store(longlong nr,...) method incompletely calculates a bit mask for the comparison with a given number: if that number is greater than 0x7F00 0000 0000 0000 (LONGLONG_MAX), it uses zero bit mask instead of 0xFFFF FFFF FFFF FFFF (ULONGLONG_MAX). Incomplete expression has been replaced with a set_bits macro call.
-
unknown authored
The unsignedness of large integer user variables was not being properly preserved when feeded to prepared statements. This was happening because the unsigned flags wasn't being updated when converting the user variable is converted to a parameter. The solution is to copy the unsigned flag when converting the user variable to a parameter and take the unsigned flag into account when converting the integer to a string. mysql-test/r/binlog.result: Add test case result for Bug#33798 mysql-test/r/ps.result: Add test case result for Bug#33798 mysql-test/t/binlog.test: Add test case for Bug#33798 mysql-test/t/ps.test: Add test case for Bug#33798 sql/item.cc: Take the unsigned flag into account when converting the user variable.
-
unknown authored
The out of memory error was thrown when the sort buffer size were too small. This led to a user confusion. Now filesort throws the error message about sort buffer being too small. mysql-test/t/order_by.test: Added a test case for the bug#31590: Wrong error message on sort buffer being too small. mysql-test/r/order_by.result: Added a test case for the bug#31590: Wrong error message on sort buffer being too small. sql/filesort.cc: Bug#31590: Wrong error message on sort buffer being too small. Now filesort throws the error message about sort buffer being too small instead of out of memory error.
-
- 07 Feb, 2008 7 commits
-
-
unknown authored
-
unknown authored
into mysql.com:/home/psergey/mysql-5.0-bug27732
-
unknown authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-runtime client/mysqltest.c: Auto merged
-
unknown authored
into host.loc:/home/uchum/work/5.0-opt
-
unknown authored
Minor post-fix for bug#34223. mysql-test/r/innodb_mysql.result: Minor post-fix for bug#34223. mysql-test/r/variables.result: Minor post-fix for bug#34223. mysql-test/t/innodb_mysql.test: Minor post-fix for bug#34223. mysql-test/t/variables.test: Minor post-fix for bug#34223.
-
unknown 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. sql/handler.cc: BUG#27732 "Possible memory leak with index_merge" - 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
-
unknown authored
into host.loc:/home/uchum/work/5.0-opt
-