- 08 Aug, 2011 4 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Vladislav Vaintroub authored
The reason for the long shutdown is hanging in io threads. It appears that just closing completion port on XP does not necessarily signal thread waiting in GetIOCompletionStatus() (even if this works fine on later Windows versions) The fix is to wakeup background threads using PostQueuedCompletionStatus() with a special 'key' parameter indicating shutdown.
-
Vladislav Vaintroub authored
The reason for the crash is Innodb assertion after trying to load condition variables function dynamically and not finding them The fix is to skip dynamic loading if srv_use_native_conditions is FALSE. srv_use_native_conditions is derived from Windows version and would be FALSE on XP and TRUE on later Windows. This is the same handling as in MySQL 5.. In Maria 5.3 srv_use_native_conditions check was presumably lost in the downporting.
-
- 05 Aug, 2011 2 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
revno: 2876.47.174 revision-id: jorgen.loland@oracle.com-20110519120355-qn7eprkad9jqwu5j parent: mayank.prasad@oracle.com-20110518143645-bdxv4udzrmqsjmhq committer: Jorgen Loland <jorgen.loland@oracle.com> branch nick: mysql-trunk-11765831 timestamp: Thu 2011-05-19 14:03:55 +0200 message: BUG#11765831: 'RANGE ACCESS' MAY INCORRECTLY FILTER AWAY QUALIFYING ROWS The problem was that the ranges created when OR'ing two conditions could be incorrect. Without the bugfix, "I <> 6 OR (I <> 8 AND J = 5)" would create these ranges: "NULL < I < 6", "6 <= I <= 6 AND 5 <= J <= 5", "6 < I < 8", "8 <= I <= 8 AND 5 <= J <= 5", "8 < I" While the correct ranges is "NULL < I < 6", "6 <= I <= 6 AND 5 <= J <= 5", "6 < I" The problem occurs when key_or() ORs (1) "NULL < I < 6, 6 <= I <= 6 AND 5 <= J <= 5, 6 < I" with (2) "8 < I AND 5 <= J <= 5" The reason for the bug is that in key_or(), SEL_ARG *tmp is used to point to the range in (1) above that is merged with (2) while key1 points to the root of the red-black tree of (1). When merging (1) and (2), tmp refers to the "6 < I" part whereas the root is the "6 <= ... AND 5 <= J <= 5" part. key_or() decides that the tmp range needs to be split into "6 < I < 8, 8 <= I <= 8, 8 < I", in which next_key_part of the second range should be that of tmp. However, next_key_part is set to key1->next_key_part ("5 <= J <= 5") instead of tmp->next_key_part (empty). Fixing this gives the correct but not optimal ranges: "NULL < I < 6", "6 <= I <= 6 AND 5 <= J <= 5", "6 < I < 8", "8 <= I <= 8", "8 < I" A second problem can be seen above: key_or() may create adjacent ranges that could be replaced with a single range. Fixes for this is also included in the patch so that the range above becomes correct AND optimal: "NULL < I < 6", "6 <= I <= 6 AND 5 <= J <= 5", "6 < I" Merging adjacent ranges like this gives a slightly lower cost estimate for the range access.
-
- 04 Aug, 2011 1 commit
-
-
Sergey Petrunya authored
revno: 3363.3.16 revision-id: jorgen.loland@oracle.com-20110506132631-5wickj6dvrh1dpj6 parent: alexander.nozdrin@oracle.com-20110506132138-46459va9vcbd4nz0 committer: Jorgen Loland <jorgen.loland@oracle.com> branch nick: mysql-trunk-11765831 timestamp: Fri 2011-05-06 15:26:31 +0200 message: BUG#11765831: 'RANGE ACCESS' MAY INCORRECTLY FILTER AWAY QUALIFYING ROWS Preparation patch (does not include fix for the bug): * Extensively document key_or() * Remove tab indentations from key_or() * Minor code changes like using existing utility functions in key_or()
-
- 03 Aug, 2011 2 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
LPBug#819711 : optimizer_switch must be reported on segfault LPBug#820169: Full query text must be reported on crash
-
- 01 Aug, 2011 2 commits
- 31 Jul, 2011 3 commits
-
-
unknown authored
-
unknown authored
-
unknown authored
Problem was the parsing of test suite files for various tags and options. This was done inefficiently, and include files were re-parsed for every place they were included. This caused a delay of 20 seconds or so before the first test started to run. By parsing more efficiently and re-using first parse for subsequent inclusion of the same file, time spent parsing is reduced to less than 1 second, and start appears instantaneous. (With this patch, full ./mtr runs in 3 minutes on my laptop (release build.) mysql-test/suite/innodb_plugin/t/innodb_bug52663.test: Test is fairly slow, so try to avoid getting stuck with it at the end while other workers are idle.
-
- 30 Jul, 2011 1 commit
-
-
Igor Babaev authored
This problem could be observed for queries with nested outer joins for which the not_exist optimization were applicable. The problem was caused by the code of the patch for bug #49322 that erroneously forced the return to the previous nested loop level when the join algorithm successfully builds a partial record for an embedded outer to which the not_exist optimization could be applied. Actually the immediate return to the previous nested loops level is correct only if this partial record is rejected by a predicate pushed down to one of the inner tables of this outer join. Otherwise attempts to find extensions of this record must be made.
-
- 28 Jul, 2011 1 commit
-
-
unknown authored
sql/sql_expression_cache.cc: Do not go on disk if hit rate is not good. Local hit/miss counters added. sql/sql_expression_cache.h: Local hit/miss counters added.
-
- 26 Jul, 2011 1 commit
-
-
Michael Widenius authored
Fixed lp:814237: Wrong mutex usage in Aria storage/maria/ma_bitmap.c: Added call to _ma_bitmap_mark_file_changed() when flushing bitmap. This fixes lp:814237
-
- 24 Jul, 2011 2 commits
-
-
Michael Widenius authored
scripts/mysqldumpslow.sh: Remove not used --basedir option Ensure that the last --datadir option is used from the my.cnf files.
-
Michael Widenius authored
The bug happens when one uses MAX_ROWS=# with Aria & row_format=page and one insert more than # rows. mysql-test/mysql-test-run.pl: Ignore table is full error messages mysql-test/suite/maria/r/max_length.result: Test case for 'Table is full' mysql-test/suite/maria/t/max_length.test: Test case for 'Table is full' storage/maria/ma_bitmap.c: Ensure that we don't allocate bits outside of max_data_file_size. Adjust max_data_file_size based on bitmap alignments. Backport fix to adjust wrong first_bitmap_with_space. storage/maria/ma_blockrec.c: Calculate value of max_data_file_length storage/maria/ma_blockrec.h: Updated prototype for _ma_bitmap_init() storage/maria/ma_check.c: Give warnings if file sizes are above max file sizes. Give more warnings in case of errors. Have maria_chk write if table is recreated. storage/maria/ma_create.c: Better calculation of max_data_file_length and thus data pointer length. Fixes some wrong pointer lengths when using MAX_ROWS=# storage/maria/ma_open.c: Removed duplicate assigment. Use block size from file instead of global variable. storage/maria/maria_chk.c: Remove -1 from printed file length storage/maria/maria_def.h: Update struct st_maria_file_bitmap
-
- 23 Jul, 2011 2 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
the optimizer switch.
-
- 21 Jul, 2011 14 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
off by default.
-
unknown authored
In case of two views with subqueries it is dificult to decide about order of injected ORDER BY clauses. A simple solution is just prohibit ORDER BY injection if there is other order by. mysql-test/r/view.result: New test added, old test changed. mysql-test/t/view.test: New test aded. sql/share/errmsg.txt: new warning added. sql/sql_view.cc: Inject ORDER BY only if there is no other one. Warning about ignoring ORDER BY in this case for EXPLAIN EXTENDED.
-
unknown authored
-
Sergey Petrunya authored
- Correct handling of outer joins + DuplicateWeedout (docs pending)
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
Fixed explains of previous patch. mysql-test/r/explain.result: Fixed explains of previous patch. mysql-test/r/join_outer.result: Fixed explains of previous patch. mysql-test/r/negation_elimination.result: Fixed explains of previous patch. mysql-test/r/view.result: Fixed explains of previous patch. mysql-test/suite/innodb/r/innodb_mysql.result: Removed duplicate test suite. mysql-test/suite/innodb/t/innodb_mysql.test: Removed duplicate test suite. mysql-test/suite/innodb_plugin/r/innodb_mysql.result: Removed duplicate test suite. mysql-test/suite/innodb_plugin/t/innodb_mysql.test: Removed duplicate test suite. sql/opt_range.h: Removed incorrect fix. sql/records.cc: Removed incorrect fix.
-
unknown authored
-
unknown authored
There are 2 volatile condition constructions AND/OR constructions and fields(references) when first good supported to be top elements of conditions because it is normal practice (see copy_andor_structure for example) fields without any expression in the condition is really rare and mostly useless case however it could lead to problems when optimiser changes/moves them unaware of other variables referring to them. An easy solution of this problem is just to replace single field in a condition with equivalent expression well supported by the server (<field> -> <field> != 0). mysql-test/r/view.result: New test added. mysql-test/t/view.test: New test added. sql/sql_parse.cc: <field> -> <field> != 0 sql/sql_yacc.yy: <field> -> <field> != 0
-
Igor Babaev authored
Do not make substitution of a single-row table if it is an inner table of an outer join with on expression containing an expensive subquery.
-
Igor Babaev authored
An aggregating query over an empty set of a join of two tables with a rejecting HAVING clause erroneously could return a row. It could happen in the cases when the optimizer made a conclusion that the aggregating set was empty. Wrong results were produced because the server missed initial setting for aggregation functions in the mentioned cases.
-
- 20 Jul, 2011 5 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
-
Igor Babaev authored
of the patch for bug 780386.
-
unknown authored
ALL subquery should return TRUE if subquery rowa set is empty independently of left part. The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not call execution of second argument if first is NULL no in this case subquery will not be executed and when Item_func_not_all calls any_value() of the subquery or aggregation function which report that there was rows. So for NULL < ALL (SELECT...) result was FALSE instead of TRUE. Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with changing the operation if it is needed) so that result will be the same (for examole a < b is equal to b > a). This fix exploit the fact that first argument will be executed in any case. mysql-test/r/subselect.result: The test suite added. mysql-test/r/subselect_no_mat.result: The test suite added. mysql-test/r/subselect_no_opts.result: The test suite added. mysql-test/r/subselect_no_semijoin.result: The test suite added. mysql-test/r/subselect_scache.result: The test suite added. mysql-test/t/subselect.test: The test suite added. sql/item_cmpfunc.cc: Swap arguments creation methods added. sql/item_cmpfunc.h: Swap arguments creation methods added. sql/item_subselect.cc: Swap arguments of the comparison.
-
Sergey Petrunya authored
-