- 03 Aug, 2007 2 commits
-
-
gshchepa@dl145s.mysql.com authored
Post-merge fix.
-
gshchepa/uchum@gleb.loc authored
Post-merge fix.
-
- 02 Aug, 2007 9 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
The SELECT query with more than 31 nested dependent SELECT queries returned wrong result. New error message has been added: ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT. It will be reported as: "Too high level of nesting for select".
-
evgen@moonbone.local authored
Post merge changes.
-
evgen@moonbone.local authored
After merge changes.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/test-5.1-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/test-5.1-opt-mysql
-
gkodinov/kgeorge@magare.gmz authored
keep_files_on_create made a startup option
-
- 31 Jul, 2007 22 commits
-
-
gkodinov/kgeorge@magare.gmz authored
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/24989-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
Warning fixed.
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B27417-5.0-opt
-
sergefp@mysql.com authored
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B27417-5.1-opt
-
gkodinov/kgeorge@magare.gmz authored
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B27417-5.1-opt
-
gkodinov/kgeorge@magare.gmz authored
extend the assert so it will run the testsuite
-
sergefp@pylon.mylan authored
into mysql.com:/home/psergey/mysql-5.0-bug29582
-
sergefp@mysql.com authored
- Don't call mysql_select() several times for the select that enumerates a temporary table with the results of the UNION. Making this call for every subquery execution caused O(#enumerated-rows-in-the-outer-query) memory allocations. - Instead, call join->reinit() and join->exec(), and = disable constant table detection for such joins, = provide special handling for table-less constant subqueries.
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
gshchepa/uchum@gleb.loc authored
Post-merge fix.
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29717/my50-29717
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29717/my51-29717
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29717/my50-29717
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/29717/my41-29717
-
holyfoot/hf@mysql.com/hfmain.(none) authored
SELECT statement itself returns empty. As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY' can return one row instead of an empty result set. When GROUP BY only has fields of constant tables (with a single row), the optimizer deletes the group_list. After that we lose the information about whether we had an GROUP BY statement. Though it's important as SELECT min(x) from empty_table; and SELECT min(x) from empty_table GROUP BY y; have to return different results - the first query should return one row, second - an empty result set. So here we add the 'group_optimized_away' flag to remember this case when GROUP BY exists in the query and is removed by the optimizer, and check this flag in end_send_group()
-
- 30 Jul, 2007 7 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
gshchepa/uchum@gleb.loc authored
Fixing a typo in the test case.
-
gkodinov/kgeorge@magare.gmz authored
Merge magare.gmz:/home/kgeorge/mysql/work/B27417-5.0-opt into magare.gmz:/home/kgeorge/mysql/work/B27417-5.1-opt
-
gkodinov/kgeorge@magare.gmz authored
Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack Once had been set the flag might later got reset inside of a stored routine execution stack. The reason was in that there was no check if a new statement started at time of resetting. The artifact affects most of binlogable DML queries. Notice, that multi-update is wrapped up within bug@27716 fix, multi-delete bug@29136. Fixed with saving parent's statement flag of whether the statement modified non-transactional table, and unioning (merging) the value with that was gained in mysql_execute_command. Resettling thd->no_trans_update members into thd->transaction.`member`; Asserting code; Effectively the following properties are held. 1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table reflects the fact if such a table got modified by the substatement. That also respects THD::really_abort_on_warnin() requirements. 2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as the union of the values of all invoked sub-statements. That fixes this bug#27417; Computing of thd->transaction.all.modified_non_trans_table is refined to base to the stmt's value for all the case including insert .. select statement which before the patch had an extra issue bug@28960. Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in to temp_table select. The supplied test verifies limitely, mostly asserts. The ultimate testing is defered for bug@13270, bug@23333.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/24989-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
When innodb detects a deadlock it calls ha_rollback_trans() to rollback the main transaction. But such action isn't allowed from inside of triggers and functions. When it happen the 'Explicit or implicit commit' error is thrown even if there is no commit/rollback statements in the trigger/function. This leads to the user confusion. Now the convert_error_code_to_mysql() function doesn't call the ha_rollback_trans() function directly but rather calls the mark_transaction_to_rollback function and returns an error. The sp_rcontext::find_handler() now doesn't allow errors to be caught by the trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag is set. Procedures are still allowed to catch such errors. The sp_rcontext::find_handler function now accepts a THD handle as a parameter. The transaction_rollback_request and the is_fatal_sub_stmt_error flags are added to the THD class. The are initialized by the THD class constructor. Now the ha_autocommit_or_rollback function rolls back main transaction when not in a sub statement and the thd->transaction_rollback_request is set. The THD::restore_sub_statement_state function now resets the thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.
-
gkodinov/kgeorge@magare.gmz authored
a place where it would not obstruct correct multithreading.
-