summaryrefslogtreecommitdiff
path: root/mysql-test/t
Commit message (Collapse)AuthorAgeFilesLines
* BUG#1002630: Valgrind warnings 'Invalid read' in ↵Sergey Petrunya2012-05-251-0/+17
| | | | | | | | subselect_engine::calc_const_tables with SELECT - In JOIN::exec(), make the having->update_used_tables() call before we've made the JOIN::cleanup(full=true) call. The latter frees SJ-Materialization structures, which correlated subquery predicate items attempt to walk afterwards.
* BUG#1000051: Query with simple join and ORDER BY takes thousands times ↵Sergey Petrunya2012-05-231-3/+6
| | | | | | | longer when run with ICP - Correct testcases.
* BUG#1000051: Query with simple join and ORDER BY takes thousands times ↵Sergey Petrunya2012-05-231-0/+17
| | | | | | longer when run with ICP - Disable IndexConditionPushdown for reverse scans.
* Fix bug lp:1002079unknown2012-05-221-0/+15
| | | | | | | | | | | | | | | | | Analysis: The optimizer detects an empty result through constant table optimization. Then it calls return_zero_rows(), which in turns calls inderctly Item_maxmin_subselect::no_rows_in_result(). The latter method set "value=0", however "value" is pointer to Item_cache, and not just an integer value. All of the Item_[maxmin | singlerow]_subselect::val_XXX methods does: if (forced_const) return value->val_real(); which of course crashes when value is a NULL pointer. Solution: When the optimizer discovers an empty result set, set Item_singlerow_subselect::value to a FALSE constant Item instead of NULL.
* MDEV-136 Non-blocking "set read_only".Alexey Botchkov2012-05-211-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Handle the 'set read_only=1' in lighter way, than the FLUSH TABLES READ LOCK; For the transactional engines we don't wait for operations on that tables to finish. per-file comments: mysql-test/r/read_only_innodb.result MDEV-136 Non-blocking "set read_only". test result updated. mysql-test/t/read_only_innodb.test MDEV-136 Non-blocking "set read_only". test case added. sql/mysql_priv.h MDEV-136 Non-blocking "set read_only". The close_cached_tables_set_readonly() declared. sql/set_var.cc MDEV-136 Non-blocking "set read_only". Call close_cached_tables_set_readonly() for the read_only::set_var. sql/sql_base.cc MDEV-136 Non-blocking "set read_only". Parameters added to the close_cached_tables implementation, close_cached_tables_set_readonly declared. Prevent blocking on the transactional tables if the set_readonly_mode is on.
* 5.2 mergeSergei Golubchik2012-05-2014-3/+484
|\
| * 5.1 mergeSergei Golubchik2012-05-1813-3/+471
| |\
| | * merge with mysql-5.1.63Sergei Golubchik2012-05-1713-3/+471
| | |\
| | | * merge mysql-5.1->mysql-5.1-securityGeorgi Kodinov2012-04-105-2/+181
| | | |\
| | | | * Bug #11766072 59107: MYSQLSLAP CRASHES IF STARTED WITH NO ARGUMENTS ON WINDOWSVenkata Sidagam2012-04-091-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug is a duplicate of Bug #31173, which was pushed to the mysql-trunk 5.6 on 4th Aug, 2010. This is just a back-port of the fix mysql-test/r/mysqlslap.result: A test added as part of the fix for Bug #59107 mysql-test/t/mysqlslap.test: A test added as part of the fix for Bug #59107
| | | | * Bug#11763507 - 56224: FUNCTION NAME IS CASE-SENSITIVEPraveenkumar Hulakund2012-03-283-21/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis: ------------------------------- According to the Manual (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html): "Column, index, stored routine, and event names are not case sensitive on any platform, nor are column aliases." In other words, 'lower_case_table_names' does not affect the behaviour of those identifiers. On the other hand, trigger names are case sensitive on some platforms, and case insensitive on others. 'lower_case_table_names' does not affect the behaviour of trigger names either. The bug was that SHOW statements did case sensitive comparison for stored procedure / stored function / event names. Fix: Modified the code so that comparison in case insensitive for routines and events for "SHOW" operation. As part of this commit, only fixing the test failures due to the actual code fix.
| | | | * Backport of fix for Bug#12763207 - ASSERT IN SUBSELECT::SINGLE_VALUE_TRANSFORMERTor Didriksen2012-03-271-0/+55
| | | | |
| | | | * Bug#11763507 - 56224: FUNCTION NAME IS CASE-SENSITIVEPraveenkumar Hulakund2012-03-271-0/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis: ------------------------------- According to the Manual (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html): "Column, index, stored routine, and event names are not case sensitive on any platform, nor are column aliases." In other words, 'lower_case_table_names' does not affect the behaviour of those identifiers. On the other hand, trigger names are case sensitive on some platforms, and case insensitive on others. 'lower_case_table_names' does not affect the behaviour of trigger names either. The bug was that SHOW statements did case sensitive comparison for stored procedure / stored function / event names. Fix: Modified the code so that comparison in case insensitive for routines and events for "SHOW" operation.
| | | | * Merge from mysql-5.1.62-releaseunknown2012-03-204-0/+156
| | | | |\
| | | * | | Bug#11766300 59387: FAILING ASSERTION: CURSOR->POS_STATE == 1997660512 ↵Sergey Glukhov2012-04-041-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (BTR_PCUR_IS_POSITIONE Bug#13639204 64111: CRASH ON SELECT SUBQUERY WITH NON UNIQUE INDEX The crash happened due to wrong calculation of key length during creation of reference for sort order index. The problem is that keyuse->used_tables can have OUTER_REF_TABLE_BIT enabled but used_tables parameter(create_ref_for_key() func) does not have it. So key parts which have OUTER_REF_TABLE_BIT are ommited and it could lead to incorrect key length calculation(zero key length). mysql-test/r/subselect_innodb.result: test result mysql-test/t/subselect_innodb.test: test case sql/sql_select.cc: added OUTER_REF_TABLE_BIT to the used_tables parameter for create_ref_for_key() function. storage/innobase/handler/ha_innodb.cc: added assertion, request from Inno team storage/innodb_plugin/handler/ha_innodb.cc: added assertion, request from Inno team
| | | * | | Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVERNorvald H. Ryeng2012-03-121-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Grouping results by VALUES(alias for string literal) causes the server to crash. Item_insert_values is not constructed to handle other types of arguments than field and reference to field. In this case, the argument is an Item_string, and this causes Item_insert_values::fix_fields() to crash. Fix: Issue an error message when the argument to Item_insert_values is not a field or a reference to a field. This is slightly in breach with documentation, which states that VALUES should return NULL, but the error message is only issued in cases where the server otherwise would crash, so there is no change in behavior for queries that already work. Future versions will restrict syntax so that using VALUES in this way is illegal. mysql-test/r/errors.result: Add test case for bug #13031606. mysql-test/t/errors.test: Add test case for bug #13031606. sql/item.cc: Issue error message if argument is not field or reference to field.
| | | * | | Fixed test case for bug #13105873 "valgrind warning:possibleDmitry Lenev2012-03-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | crash in foreign key handling on subsequent create table if not exists". Do not leave current database unassigned after the end of the test case.
| | | * | | merge mysql-5.1->mysql-5.1-securityGeorgi Kodinov2012-03-084-1/+188
| | | |\ \ \ | | | | |/ /
| | | | * | merge into mysql-5.1Mattias Jonsson2012-02-292-1/+21
| | | | |\ \
| | | | | * | Bug#11761296: 53775: QUERY ON PARTITIONED TABLE RETURNS CACHEDMattias Jonsson2012-02-202-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RESULT FROM PREVIOUS TRANSACTION The current Query Cache API is not fully compatible with the partitioning engine. There is no good way to implement support for QC due to: 1) a static callback for ha_partition would need to have access to all partition names and call the underlying callback for each [sub]partition with the correct name. 2) pruning would be impossible, even if one used the ulonglong engine_data due to if engine_data is changed, the table is invalidated by the QC. So the only viable solution to avoid incorrect data is to not allow caching of queries using partitioned tables. (There are some extra changes, due to removal of \r as line break)
| | | | * | | Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND ↵Praveenkumar Hulakund2012-02-291-0/+154
| | | | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BREAKS REPLICATION Analysis: ======================== sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input, instead of escape character in a string literal then sql_mode can be set to "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary character like any other. SQL_MODE set applies to the current client session. And while creating the stored procedure, MySQL stores the current sql_mode and always executes the stored procedure in sql_mode stored with the Procedure, regardless of the server SQL mode in effect when the routine is invoked. In the scenario (for which bug is reported), the routine is created with sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode is "" (NOT SET) by executing statement "call testp('Axel\'s')". Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function) is considered as escape character and column "a" (of table "t1") values are updated with "Axel's". The binary log generated for above update operation is as below, set sql_mode=XXXXXX (for no_backslash_escapes) update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci'); While logging stored procedure statements, the local variables (params) used in statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const) On slave, these logs are applied. NAME_CONST is parsed to get the variable and its value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode is also logged in. So that at slave this sql_mode is set before executing the statements of routine. So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character and parsing reported error for "'" (as we have only one "'" no backslash). At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES". But above error reported while writing bin log, "'" (of Axel's) is escaped with "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped while writing NAME_CONST for string variable(param, local variable) in bin log irrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is that logging string parameter does not take into account sql_mode value. Fix: ======================== So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping characters as (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to escape such characters while writing NAME_CONST for string variables in bin log. And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is represented as ''. http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several ways to include quote characters within a string: )
| | | | | * | | Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND ↵Praveenkumar Hulakund2012-02-291-0/+154
| | | | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BREAKS REPLICATION Analysis: ======================== sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input, instead of escape character in a string literal then sql_mode can be set to "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary character like any other. SQL_MODE set applies to the current client session. And while creating the stored procedure, MySQL stores the current sql_mode and always executes the stored procedure in sql_mode stored with the Procedure, regardless of the server SQL mode in effect when the routine is invoked. In the scenario (for which bug is reported), the routine is created with sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode is "" (NOT SET) by executing statement "call testp('Axel\'s')". Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function) is considered as escape character and column "a" (of table "t1") values are updated with "Axel's". The binary log generated for above update operation is as below, set sql_mode=XXXXXX (for no_backslash_escapes) update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci'); While logging stored procedure statements, the local variables (params) used in statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const) On slave, these logs are applied. NAME_CONST is parsed to get the variable and its value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode is also logged in. So that at slave this sql_mode is set before executing the statements of routine. So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character and parsing reported error for "'" (as we have only one "'" no backslash). At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES". But above error reported while writing bin log, "'" (of Axel's) is escaped with "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped while writing NAME_CONST for string variable(param, local variable) in bin log Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is that logging string parameter does not take into account sql_mode value. Fix: ======================== So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping characters as (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to escape such characters while writing NAME_CONST for string variables in bin log. And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is represented as ''. http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several ways to include quote characters within a string: ) mysql-test/r/sql_mode.result: Added test case for Bug#12601974. mysql-test/suite/binlog/r/binlog_sql_mode.result: Appended result of test cases added for Bug#12601974. mysql-test/suite/binlog/t/binlog_sql_mode.test: Added test case for Bug#12601974. mysql-test/t/sql_mode.test: Appended result of test cases added for Bug#12601974.
| | | | * | | Bug#13012483:EXPLAIN EXTENDED, PREPARED STATEMENT, CRASH INChaithra Gopalareddy2012-02-241-0/+13
| | | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CHECK_SIMPLE_EQUALITY PROBLEM: Crash in "check_simple_equality" when using a subquery with "IN" and "ALL" in prepare. ANALYSIS: Crash can be reproduced using a simplified query like this one: prepare s from "select 1 from g1 where 1 < all ( select @:=(1 in (select 1 from g1)) from g1)"; This bug is currently present only on 5.5.and 5.1. Its fixed as part of work log(#1110) in 5.6. We are taking one change to fix this in 5.5 and 5.1. Problem seems to be present because we are trying to evaluate "is_null" on an argument which is part of a subquery (In Item_is_not_null_test::update_used_tables()). But the condition to evaluate is only when we do not have a sub query present, which means to say that "with_subselect" is not set. With respect to the above query, we create an object of type "Item_in_optimizer" which by definition is always associated with a subquery. While in 5.6 we set "with_subselect" to true for "Item_in_optimizer" object, we do not do the same in 5.5. This results in the evaluation for "is_null" resulting in a coredump. So, we are now setting "with_subselect" to true for "Item_in_optimizer" in 5.1 and 5.5. mysql-test/r/func_in.result: Result file changes for the test case added mysql-test/t/func_in.test: Test case added for Bug#13012483 sql/item_cmpfunc.h: Changed Item_in_optimizer::Item_in_optimizer( ) to set "with_subselect" to true
| | | * | | BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN Ramil Kalimullin2012-03-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GEOMETRY FUNCTION ARGUMENTS Fixed --ps-protocol gis test failure.
| | | * | | BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ↵Ramil Kalimullin2012-03-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ARGUMENTS A defect in the subquery substitution code may lead to a server crash: setting substitution's name should be followed by setting its length (to keep them in sync). mysql-test/r/gis.result: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS test result. mysql-test/t/gis.test: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS test case. sql/item_subselect.cc: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS set substitution's name length as well as the name itself (to keep them in sync).
| | | * | | Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS Ramil Kalimullin2012-03-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: lack of incoming geometry data validation may lead to a server crash when ISCLOSED() function called. Solution: necessary incoming data check added. mysql-test/r/gis.result: Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS test result. mysql-test/t/gis.test: Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS test case. sql/spatial.cc: Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS check if a LINESTRING has at least one point as we rely on that further.
| | | * | | Bug#13519724 63793: CRASH IN DTCOLLATION::SET(DTCOLLATION &SET)Tor Didriksen2012-02-221-0/+12
| | | | |/ | | | |/| | | | | | | | | | | | | | | | | | | | | Backport of fix for: Bug#53236 Segfault in DTCollation::set(DTCollation&)
| * | | | fix of LP bug#998321unknown2012-05-171-0/+13
| | | | | | | | | | | | | | | | | | | | The problem is that we can't check null_value field of non-basic constant without the item execution.:
* | | | | MergeSergey Petrunya2012-05-181-0/+13
|\ \ \ \ \
| * | | | | BUG#1000269: Wrong result (extra rows) with semijoin+materialization, IN ↵Sergey Petrunya2012-05-181-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subqueries, join_cache_level>0 - make make_cond_after_sjm() correctly handle OR clauses where one branch refers to the semi-join table while the other branch refers to the non-semijoin table.
* | | | | | Test suite of fixed bug (LP bug#993459).unknown2012-05-172-2/+126
| | | | | |
* | | | | | Fix for LP bug#998516unknown2012-05-151-0/+13
|/ / / / / | | | | | | | | | | | | | | | | | | | | If we did nothing in resolving unique table conflict we should not retry (it leed to infinite loop). Now we retry (recheck) unique table check only in case if we materialized a table.
* | | | | BUG#998236: Assertion failure or valgrind errors at best_access_path ...Sergey Petrunya2012-05-131-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Let fix_semijoin_strategies_for_picked_join_order() set POSITION::prefix_record_count for POSITION records that it copies from SJ_MATERIALIZATION_INFO::tables. (These records do not have prefix_record_count set, because they are optimized as joins-inside-semijoin-nests, without full advance_sj_state() processing).
* | | | | Merge 5.2->5.3Sergey Petrunya2012-05-121-0/+24
|\ \ \ \ \ | |/ / / /
| * | | | Merge 5.2->5.3Sergey Petrunya2012-05-121-0/+24
| |\ \ \ \ | | |/ / /
| | * | | BUG#997747: Assertion `join->best_read < ((double)1.79..5e+308L)' failed Sergey Petrunya2012-05-121-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in greedy_search with LEFT JOINs and unique keys - Backport the fix for BUG#806524 from MariaDB 5.3
* | | | | Merge 5.2->5.3unknown2012-05-114-9/+113
|\ \ \ \ \ | |/ / / /
| * | | | fix for LP bug#994392unknown2012-05-111-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The not_null_tables() of Item_func_not_all and Item_in_optimizer was inherited from Item_func by mistake. It made the optimizer think that subquery predicates with ALL/ANY/IN were null-rejecting. This could trigger invalid conversions of outer joins into inner joins.
| * | | | MDEV-262 : log_state occationally fails in buildbot. Vladislav Vaintroub2012-05-081-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | The failures are missing entries in the slow query log. The reason for the failure are sleep() calls with short duration 10ms, which is less than the default system timer resolution for various WaitForXXXObject functions (15.6 ms) and thus can't work reliably. The fix is to make sleeps tiny bit longer (20ms from 10ms) in the test.
| * | | | Fix for LP bug#993726unknown2012-05-071-0/+9
| | | | | | | | | | | | | | | | | | | | Optimization of aggregate functions detected constant under max() and evalueted it, but condition in the WHWRE clause (which is always FALSE) was not taken into account
| * | | | Fix for bug lp:992405unknown2012-05-071-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch backports two patches from mysql 5.6: - BUG#12640437: USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT QUERY OUTPUT - Bug#12578908: SELECT SQL_BUFFER_RESULT OUTPUTS TOO MANY ROWS WHEN GROUP IS OPTIMIZED AWAY Original comment: ----------------- 3714 Jorgen Loland 2012-03-01 BUG#12640437 - USING SQL_BUFFER_RESULT RESULTS IN A DIFFERENT QUERY OUTPUT For all but simple grouped queries, temporary tables are used to resolve grouping. In these cases, the list of grouping fields is stored in the temporary table and grouping is resolved there (e.g. by adding a unique constraint on the involved fields). Because of this, grouping is already done when the rows are read from the temporary table. In the case where a group clause may be optimized away, grouping does not have to be resolved using a temporary table. However, if a temporary table is explicitly requested (e.g. because the SQL_BUFFER_RESULT hint is used, or the statement is INSERT...SELECT), a temporary table is used anyway. In this case, the temporary table is created with an empty group list (because the group clause was optimized away) and it will therefore not create groups. Since the temporary table does not take care of grouping, JOIN::group shall not be set to false in make_simple_join(). This was fixed in bug 12578908. However, there is an exception where make_simple_join() should set JOIN::group to false even if the query uses a temporary table that was explicitly requested but is not strictly needed. That exception is if the loose index scan access method (explain says "Using index for group-by") is used to read into the temporary table. With loose index scan, grouping is resolved by the access method. This is exactly what happens in this bug.
| * | | | Fix bug lp:993745unknown2012-05-031-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a backport of the fix for MySQL bug #13723054 in 5.6. Original comment: The crash is caused by arbitrary memory area owerwriting in case of BLOB fields during attempt to copy BLOB field key image into record buffer(record buffer is too small to get BLOB key part image). note: QUICK_GROUP_MIN_MAX_SELECT can not work with BLOB fields because it uses record buffer as temporary buffer for key values however this case is filtered out by covering_keys() check in get_best_group_min_max() as BLOBs always require key length modificator in the key declaration and if the key has a BLOB then it can not be covered key. The fix is to use 'max_used_key_length' key length instead of 0. Analysis: Spcifically the crash in this bug was a result of the call to key_copy() that copied the whole key, inlcuding the BLOB field which is not used for index access. Copying the blob field overwrote memory as far as the function parameter 'key_info'. As a result the contents of key_info was all 0, which resulted in a crash when this key_info was accessed few lines below in key_cmp().
* | | | | LP bug#994275 fix.unknown2012-05-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | In 5.3 we substitute constants in ref access values it can't be null so we do not need add NOT NULL for early NULL filtering.
* | | | | Fix for failing gis-precise on Windows.Alexey Botchkov2012-05-031-2/+2
| | | | |
* | | | | 5.2 mergeSergei Golubchik2012-05-021-0/+39
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-214 lp:967242 Wrong result with JOIN, AND in ON condition, multi-part ↵Oleksandr Byelkin2012-05-021-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | key, GROUP BY, subquery and OR in WHERE The problem was in the code (update_const_equal_items()) which marked index parts constant independently of the place where the equality was used. In the test suite it marked t2_1.c part constant despite the fact that it connected by OR with other expression. Solution is to mark constant only top equalities connected with AND.
* | | | | MDEV-241 lp:992722 - Server crashes in get_datetime_valueSergei Golubchik2012-05-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create an Item_cache based on item's cmp_type, not result_type in subselect_engine. Use result_field in Item_cache_temporal::cache_value(), just like all other Item_cache*::cache_value() do.
* | | | | mergeVladislav Vaintroub2012-05-021-0/+7
|\ \ \ \ \ | |/ / / /
| * | | | LP993103: Wrong result with LAST_DAY('0000-00-00 00:00:00')IS NULL in WHERE ↵Vladislav Vaintroub2012-05-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | condition Fix is to set maybe_null flag for Item_func_last_day.
* | | | | bug #977021 ST_BUFFER fails with the negative D.Alexey Botchkov2012-04-291-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Points and lines should disappear if we got negative D. To make it work properly inside the GEOMETRYCOLLECTION, we add the empty operation there. bug #986977 Assertion `!cur_p->event' failed in Gcalc_scan_iterator::arrange_event(int, int). The double->inernal coord conversion produced -0 (minus zero) on some data. That minus-zero produces invalid comparison results when compared agains plus-zero. So we fixed the gcalc_set_double() to avoid it. per-file comments: mysql-test/r/gis-precise.result result updated. mysql-test/t/gis-precise.test tests for #977021 and #986977 added. sql/gcalc_slicescan.cc bug #986977. The gcalc_set_double fixed to not produce minus-zero. sql/item_geofunc.cc bug #977021. Add the NOOP for the disappearing features.
View Lorry Controller Status