An error occurred fetching the project authors.
- 09 Nov, 2010 1 commit
-
-
Igor Babaev authored
The pushdown condition for the sorted table in a query can be complemented by the conditions from HAVING. This transformation is done in JOIN::exec pretty late after the original pushdown condition have been saved in the field pre_idx_push_select_cond for the sorted table. So this field must be updated after the inclusion of the condition from HAVING.
-
- 26 Aug, 2010 1 commit
-
-
Evgeny Potemkin authored
After fix for bug 39653 the shortest available secondary index was used for full table scan. Primary clustered key was used only if no secondary index can be used. However, when chosen secondary index includes all fields of the table being scanned it's better to use primary index since the amount of data to scan is the same but the primary index is clustered. Now the find_shortest_key function takes this into account. mysql-test/suite/innodb/r/innodb_mysql.result: Added a test case for the bug#55656. mysql-test/suite/innodb/t/innodb_mysql.test: Added a test case for the bug#55656. sql/sql_select.cc: Bug #55656: mysqldump can be slower after bug #39653 fix. The find_shortest_key function now prefers clustered primary key if found secondary key includes all fields of the table.
-
- 20 Aug, 2010 1 commit
-
-
Georgi Kodinov authored
KILL_BAD_DATA is returned Two problems discovered with the LEAST()/GREATEST() functions: 1. The check for a null value should happen even after the second call to val_str() in the args. This is important because two subsequent calls to the same Item::val_str() may yield different results. Fixed by checking for NULL value before dereferencing the string result. 2. While looping over the arguments and evaluating them the loop should stop if there was an error evaluating so far or the statement was killed. Fixed by checking for error and bailing out.
-
- 13 Aug, 2010 1 commit
-
-
Georgi Kodinov authored
The server was not checking for errors generated during the execution of Item::val_xxx() methods when copying data to the group, order, or distinct temp table's row. Fixed by extending the copy_funcs() to return an error code and by checking for that error code on the places copy_funcs() is called. Test case added.
-
- 07 Jul, 2010 1 commit
-
-
Jon Olav Hauglid authored
This crash occured after ALTER TABLE was used on a temporary transactional table locked by LOCK TABLES. Any later attempts to execute LOCK/UNLOCK TABLES, caused the server to crash. The reason for the crash was the list of locked tables would end up having a pointer to a free'd table instance. This happened because ALTER TABLE deleted the table without also removing the table reference from the locked tables list. This patch fixes the problem by making sure ALTER TABLE also removes the table from the locked tables list. Test case added to innodb_mysql.test.
-
- 14 Jun, 2010 1 commit
-
-
Vasil Dimov authored
-
- 09 Jun, 2010 1 commit
-
-
Sergey Glukhov authored
Valgrind warning happpens because of uninitialized null bytes. In row_sel_push_cache_row_for_mysql() function we fill fetch cache with necessary field values, row_sel_store_mysql_rec() is called for this and leaves null bytes untouched. Later row_sel_pop_cached_row_for_mysql() rewrites table record buffer with uninited null bytes. We can see the problem from the test case: At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached... chain which rewrites table->record[0] buffer with uninitialized null bytes. When we call 'UPDATE...' statement, compare_record uses this buffer and valgrind warning occurs. The fix is to init null bytes with default values. mysql-test/suite/innodb/r/innodb_mysql.result: test case mysql-test/suite/innodb/t/innodb_mysql.test: test case mysql-test/t/ps_3innodb.test: enable valgrind testing storage/innobase/row/row0sel.c: init null bytes with default values as they might be left uninitialized in some cases and these uninited bytes might be copied into mysql record buffer that leads to valgrind warnings on next use of the buffer.
-
- 03 Jun, 2010 1 commit
-
-
Marko Mäkelä authored
-
- 26 May, 2010 1 commit
-
-
Igor Babaev authored
Bug #39022: completed Bug #39653: reverted as invalid Bug #45640: ameliorated, simplified, optimized Bug #48483: completed Bug #49324: improved Bug #51242/52336: reverted, applied a real fix.
-
- 25 May, 2010 1 commit
-
-
Alexey Kopytov authored
bitmap_is_set(table->read_set, field_index)) UPDATE on an InnoDB table modifying the same index that is used to satisfy the WHERE condition could trigger a debug assertion under some circumstances. Since for engines with the HA_PRIMARY_KEY_IN_READ_INDEX flag set results of an index scan on a secondary index are appended by the primary key value, if a query involves only columns from the primary key and a secondary index, the latter is considered to be covering. That tricks mysql_update() to mark for reading only columns from the secondary index when it does an index scan to retrieve rows to update in case a part of that key is also being updated. However, there may be other columns in WHERE that are part of the primary key, but not the secondary one. What we actually want to do in this case is to add index columns to the existing WHERE columns bitmap rather than replace it. mysql-test/r/innodb_mysql.result: Test case for bug #53830. mysql-test/t/innodb_mysql.test: Test case for bug #53830. sql/sql_update.cc: Add index columns to the read_set bitmap, don't replace it. sql/table.cc: Added a new add_read_columns_used_by_index() function to st_table. sql/table.h: Added a new add_read_columns_used_by_index() function to st_table.
-
- 07 May, 2010 1 commit
-
-
Sergey Glukhov authored
The fix actually reverts the change introduced by the patch for bug 51494. The fact is that patches for bugs 52177&48419 fix bugs 51194&50575 as well. mysql-test/r/innodb_mysql.result: test case mysql-test/t/innodb_mysql.test: test case sql/sql_select.cc: reverted wrong fix for bug 51494
-
- 03 May, 2010 1 commit
-
-
unknown authored
The fix actually reverts the change introduced by the patch for bug 51494 The fact is that the patch for bug 52177 fixes bug 51194 as well.
-
- 28 Apr, 2010 1 commit
-
-
Georgi Kodinov authored
during an UPDATE Extended the fix for bug 29310 to multi-table update: When a table is being updated it has two set of fields - fields required for checks of conditions and fields to be updated. A storage engine is allowed not to retrieve columns marked for update. Due to this fact records can't be compared to see whether the data has been changed or not. This makes the server always update records independently of data change. Now when an auto-updatable timestamp field is present and server sees that a table handle isn't going to retrieve write-only fields then all of such fields are marked as to be read to force the handler to retrieve them.
-
- 17 Mar, 2010 1 commit
-
-
Georgi Kodinov authored
definition at engine If a single ALTER TABLE contains both DROP INDEX and ADD INDEX using the same index name (a.k.a. index modification) we need to disable in-place alter table because we can't ask the storage engine to have two copies of the index with the same name even temporarily (if we first do the ADD INDEX and then DROP INDEX) and we can't modify indexes that are needed by e.g. foreign keys if we first do DROP INDEX and then ADD INDEX. Fixed the problem by disabling in-place ALTER TABLE for these cases.
-
- 11 Mar, 2010 1 commit
-
-
unknown authored
This patch does three things: - It adds the possibility to force the execution of top-level [NOT] IN subquery predicates via the IN=>EXISTS transformation. This is done by setting both optimizer switches partial_match_rowid_merge and partial_match_table_scan to "off". - It adjusts all test cases where the complete optimizer_switch is selected because now we have two more switches. - For those test cases where the plan changes because of the new available strategies, we switch off both partial match strategies in order to force the "old" IN=>EXISTS strategy. This is done because most of these test cases specifically test bugs in this strategy. sql/opt_subselect.cc: Adds the possibility to force the execution of top-level [NOT] IN subquery predicates via the IN=>EXISTS transformation. This is done by setting both optimizer switches partial_match_rowid_merge and partial_match_table_scan to "off".
-
- 05 Mar, 2010 1 commit
-
-
Gleb Shchepa authored
consider clustered primary keys Choosing a shortest index for the covering index scan, the optimizer ignored the fact, that the clustered primary key read involves whole table data. The find_shortest_key function has been modified to take into account that fact that a clustered PK has a longest key of possible covering indices. mysql-test/r/innodb_mysql.result: Test case for bug #39653. mysql-test/t/innodb_mysql.test: Test case for bug #39653. sql/sql_select.cc: Bug #39653: find_shortest_key in sql_select.cc does not consider clustered primary keys The find_shortest_key function has been modified to take into account that fact that a clustered PK has a longest key of possible covering indices.
-
- 26 Feb, 2010 1 commit
-
-
Evgeny Potemkin authored
performance degradation. Filesort + join cache combination is preferred to full index scan because it is usually faster. But it's not the case when the index is clustered one. Now test_if_skip_sort_order function prefers filesort only if index isn't clustered. mysql-test/r/innodb_mysql.result: Added a test case for the bug#50843. mysql-test/t/innodb_mysql.test: Added a test case for the bug#50843. sql/sql_select.cc: Bug#50843: Filesort used instead of clustered index led to performance degradation. Now test_if_skip_sort_order function prefers filesort only if index isn't clustered.
-
- 29 Jan, 2010 1 commit
-
-
Georgi Kodinov authored
Fixed 2 problems : 1. test_if_order_by_key() was continuing on the primary key as if it has a primary key suffix (as the secondary keys do). This leads to crashes in ORDER BY <pk>,<pk>. Fixed by not treating the primary key as the secondary one and not depending on it being clustered with a primary key. 2. The cost calculation was trying to read the records per key when operating on ORDER BYs that order on all of the secondary key + some of the primary key. This leads to crashes because of out-of-bounds array access. Fixed by assuming we'll find 1 record per key in such cases.
-
- 15 Dec, 2009 1 commit
-
-
Sergey Petrunya authored
WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface" WL#2475 "Batched range read functions for MyISAM/InnoDb" "Index condition pushdown for MyISAM/InnoDB" Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614: There could be observed the following problems: 1. EXPLAIN did not mention pushdown conditions from on expressions in the 'extra' column. As a result if a query had no where conditions pushed down to a table, but had on conditions pushed to this table the 'extra' column in the EXPLAIN for the table missed 'using where'. 2. Conditions for ref access were not eliminated from on expressions though such conditions were eliminated from the where condition.
-
- 01 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 30 Nov, 2009 1 commit
-
-
Magne Mahre authored
SET TRANSACTION ISOLATION LEVEL is used to temporarily set the trans.iso.level for the next transaction. After the transaction, the iso.level is (re-)set to value of the session variable 'tx_isolation'. The bug is caused by setting the thd->variables.tx_isolation field to the value of the session variable upon each statement commit. It should only be set at the end of the full transaction. The fix has been to remove the setting of the variable in ha_autocommit_or_rollback if we're in a transaction, as it will be correctly set in either ha_rollback or ha_commit_one_phase. If, on the other hand, we're in autocommit mode, tx_isolation will be explicitly set here. mysql-test/t/innodb_mysql.test: "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED" sets the trans.isolation for the next transaction. We test that @@tx_isolation keeps this value during the transaction, and is only reset back to the session value at the end of the transaction.
-
- 25 Nov, 2009 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3182 [merge] > revision-id: ramil@mysql.com-20091018162655-z4dlolfx5s0zem8l > parent: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx > parent: ramil@mysql.com-20091013044327-24km05wc060ied87 > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: mysql-5.1-bugteam > timestamp: Sun 2009-10-18 21:26:55 +0500 > message: > Fix for bug#47963: Wrong results when index is used > > Problem: using null microsecond part in a WHERE condition > (e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000") > may lead to wrong results due to improper DATETIMEs > comparison in some cases. > > Fix: comparing DATETIMEs as strings we must trim trailing 0's > in such cases. > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
- 04 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
The SE API requires mysql to notify the storage engine that it's going to read certain tables at the beginning of the statement (by calling start_stmt(), store_lock() or external_lock()). These are typically called by the lock_tables(). However SHOW CREATE TABLE is not pre-locking the tables because it's not expected to access the data at all. But for some view definitions (that include comparing a date/datetime/timestamp column to a string returning scalar subquery) the JOIN::prepare may still access data when materializing the scalar non-correlated subquery in Arg_comparator::can_compare_as_dates(). Fixed by not materializing the subquery when the function is called in a SHOW/EXPLAIN/CREATE VIEW
-
- 13 Oct, 2009 1 commit
-
-
Ramil Kalimullin authored
Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000") in a WHERE condition may lead to wrong results due to improper DATETIMEs comparison in some cases. Fix: as we compare DATETIMEs as strings we must trim trailing 0's in such cases. mysql-test/r/innodb_mysql.result: Fix for bug#47963: Wrong results when index is used - test result. mysql-test/t/innodb_mysql.test: Fix for bug#47963: Wrong results when index is used - test case. sql/item.cc: Fix for bug#47963: Wrong results when index is used - comparing DATETIMEs trim trailing 0's in the microsecond part.
-
- 05 Oct, 2009 1 commit
-
-
John H. Embretsen authored
Mask part of EXPLAIN output with '#' to account for varying row count estimation. mysql-test/include/mix1.inc: Mask 'rows' column in EXPLAIN output (number varies sometimes between 1 and 2). mysql-test/r/innodb_mysql.result: Update result file after masking of rows estimation in EXPLAIN output.
-
- 15 Sep, 2009 1 commit
-
-
unknown authored
Fix some mistakes in the original merge found during review. mysql-test/include/concurrent.inc: Add missing lines mistakenly omitted in merge. mysql-test/include/mix1.inc: Revert wrong change done during merge. mysql-test/include/wait_for_status_var.inc.moved: Remove file which was accidentally not removed during conflict resolution in merge. mysql-test/r/innodb_mysql.result: Revert result file change following fixing root problem in merge.
-
- 09 Sep, 2009 1 commit
-
-
Sergey Petrunya authored
- Post-merge fixes
-
- 07 Jul, 2009 1 commit
-
-
Georgi Kodinov authored
use partial primary key if another index can prevent filesort The fix for bug #28404 causes the covering ordering indexes to be preferred unconditionally over non-covering and ref indexes. Fixed by comparing the cost of using a covering index to the cost of using a ref index even for covering ordering indexes. Added an assertion to clarify the condition the local variables should be in. mysql-test/include/mix1.inc: Bug #36259: fixed a non-stable test case mysql-test/r/innodb_mysql.result: Bug #36259 and #45828 : test case mysql-test/t/innodb_mysql.test: Bug #36259 and #45828 : test case sql/sql_select.cc: Bug #36259 and #45828 : don't consider covering indexes supperior to ref keys.
-
- 24 Jun, 2009 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2852.12.6 > tags: clone-5.1.35-build, mysql-5.1.35 > revision-id: gshchepa@mysql.com-20090513075139-g50shsfjaf1dstdn > parent: joerg@mysql.com-20090508190407-ymqxmp6daeta6fdj > committer: Gleb Shchepa <gshchepa@mysql.com> > branch nick: mysql-5.1 > timestamp: Wed 2009-05-13 12:51:39 +0500 > message: > Bug #44290: explain crashes for subquery with distinct in > SQL_SELECT::test_quick_select > > The crash was caused by an incomplete cleanup of JOIN_TAB::select > during the filesort of rows for GROUP BY clause inside a subquery. > Queries where a quick index access is replaced with filesort was > was affected. For example: > > SELECT 1 FROM > (SELECT COUNT(DISTINCT c1) FROM t1 > WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x > > Quick index access related data in the SQL_SELECT::test_quick_select > function was inconsistent after an incomplete cleanup. > This function has been completed to prevent crashes in the > SQL_SELECT::test_quick_select function.
-
- 07 Jun, 2009 1 commit
-
-
Gleb Shchepa authored
uninitialized variable used as subscript Grouping select from a "constant" InnoDB table (a table of a single row) joined with other tables caused a crash. mysql-test/r/innodb_mysql.result: Added test case for bug bug #44886. mysql-test/t/innodb_mysql.test: Added test case for bug bug #44886. sql/sql_select.cc: Bug #44886: SIGSEGV in test_if_skip_sort_order() - uninitialized variable used as subscript 1. The test_if_order_by_key function returned unitialized used_key_parts parameter in case of a "constant" InnoDB table. Calling function uses this parameter values as an array index, thus sometimes it caused a crash. The test_if_order_by_key function has been modified to set used_key_parts to 0 (no need for ordering). 2. The test_if_skip_sort_order function has been modified to accept zero used_key_parts value and to prevent an array access by negative index.
-
- 04 Jun, 2009 1 commit
-
-
Georgi Kodinov authored
When copying the Item class one must copy its attributes as well. mysql-test/r/innodb_mysql.result: Bug #36995: test case mysql-test/t/innodb_mysql.test: Bug #36995: test case sql/item.cc: Bug #36995: copy attributes in the copy constructor
-
- 25 May, 2009 1 commit
-
-
Georgi Kodinov authored
HAVING When calculating GROUP BY the server caches some expressions. It does that by allocating a string slot (Item_copy_string) and assigning the value of the expression to it. This effectively means that the result type of the expression can be changed from whatever it was to a string. As this substitution takes place after the compile-time result type calculation for IN but before the run-time type calculations, it causes the type calculations in the IN function done at run time to get unexpected results different from what was prepared at compile time. In the CASE ... WHEN ... THEN ... statement there was a similar problem and it was solved by artificially adding a STRING argument to the set of types of the IN/CASE arguments at compile time, so if any of the arguments of the CASE function changes its type to a string it will still be covered by the information prepared at compile time. mysql-test/include/mix1.inc: Bug #44399: extended the test to cover the different types mysql-test/r/func_in.result: Bug #44399: test case mysql-test/r/innodb_mysql.result: Bug #44399: extended the test to cover the different types mysql-test/t/func_in.test: Bug #44399: test case sql/item.cc: Bug #44399: Implement typed caching for GROUP BY sql/item.h: Bug #44399: Implement typed caching for GROUP BY sql/item_cmpfunc.cc: Bug #44399: remove the special case sql/sql_select.cc: Bug #44399: Implement typed caching for GROUP BY
-
- 19 May, 2009 1 commit
-
-
Sergey Glukhov authored
Internal InnoDN FK parser does not recognize '\'' as quotation symbol. Suggested fix is to add '\'' symbol check for quotation condition (dict_strip_comments() function). innobase/dict/dict0dict.c: Internal InnoDN FK parser does not recognize '\'' as quotation symbol. Suggested fix is to add '\'' symbol check for quotation condition (dict_strip_comments() function). mysql-test/r/innodb_mysql.result: test result mysql-test/t/innodb_mysql.test: test case
-
- 13 May, 2009 1 commit
-
-
Gleb Shchepa authored
SQL_SELECT::test_quick_select The crash was caused by an incomplete cleanup of JOIN_TAB::select during the filesort of rows for GROUP BY clause inside a subquery. Queries where a quick index access is replaced with filesort was was affected. For example: SELECT 1 FROM (SELECT COUNT(DISTINCT c1) FROM t1 WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function. mysql-test/include/mix1.inc: Add test case for bug #44290. mysql-test/r/innodb_mysql.result: Add test case for bug #44290. sql/sql_select.cc: Bug #44290: explain crashes for subquery with distinct in SQL_SELECT::test_quick_select Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function.
-
- 12 May, 2009 1 commit
-
-
Gleb Shchepa authored
SQL_SELECT::test_quick_select The crash was caused by an incomplete cleanup of JOIN_TAB::select during the filesort of rows for GROUP BY clause inside a subquery. Queries where a quick index access is replaced with filesort was was affected. For example: SELECT 1 FROM (SELECT COUNT(DISTINCT c1) FROM t1 WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function. mysql-test/include/mix1.inc: Add test case for bug #44290. mysql-test/r/innodb_mysql.result: Add test case for bug #44290. sql/sql_select.cc: Bug #44290: explain crashes for subquery with distinct in SQL_SELECT::test_quick_select Quick index access related data in the SQL_SELECT::test_quick_select function was inconsistent after an incomplete cleanup. This function has been completed to prevent crashes in the SQL_SELECT::test_quick_select function.
-
- 05 May, 2009 1 commit
-
-
Martin Hansson authored
Certain multi-updates gave different results on InnoDB from to MyISAM, due to on-the-fly updates being used on the former and the update order matters. Fixed by turning off on-the-fly updates when update order dependencies are present. mysql-test/r/innodb_mysql.result: Bug#43580: Test result. mysql-test/suite/rpl/r/rpl_slave_skip.result: Bug#43580: Changed test result. The InnoDB result is now what it would have been on MyISAM. mysql-test/t/innodb_mysql.test: Bug#43580: Test case. sql/sql_base.cc: Bug#43580: Added a word of caution about using tmp_set here. sql/sql_update.cc: Bug#43580: Fix. Calls to TABLE::mark_columns_needed_for_update() are moved from mysql_multi_update_prepare() and right before the decison to do on-the-fly updates to the place where we do (or don't do) on-the-fly updates.
-
- 30 Apr, 2009 1 commit
-
-
Daniel Fischer authored
-
- 27 Mar, 2009 2 commits
-
-
Kristofer Pettersson authored
on 5.0 The server crashes on an assert in net_end_statement indicating that the Diagnostics area wasn't set properly during execution. This happened on a multi table DELETE operation using the IGNORE keyword. The keyword is suppose to allow for execution to continue on a best effort despite some non-fatal errors. Instead execution stopped and no client response was sent which would have led to a protocol error if it hadn't been for the assert. This patch corrects this issue by checking for the existence of an IGNORE option before setting an error state during row-by-row delete iteration. mysql-test/r/innodb_mysql.result: * Added test case for bug40127 mysql-test/t/innodb_mysql.test: * Added test case for bug40127 sql/sql_delete.cc: * IGNORE option wasn't implemented in multi_delete::send_data and multi_delete::do_deletes
-
Ramil Kalimullin authored
Problem: commit doesn't delete savepoints if there are no changes in the transaction. Fix: delete them in such cases. mysql-test/r/innodb_mysql.result: Fix for bug #26288: savepoint not deleted, comit on empty transaction - test result. mysql-test/t/innodb_mysql.test: Fix for bug #26288: savepoint not deleted, comit on empty transaction - test case. sql/handler.cc: Fix for bug #26288: savepoint not deleted, comit on empty transaction - call transaction.cleanup() even if nht is 0 to delete possible savepoints.
-
- 20 Feb, 2009 1 commit
-
-
Georgi Kodinov authored
Moved the test case for the bug into a separate file (and restored the original innodb_mysql test setup). Used the new wait_show_condition test macro to avoid the usage of sleep mysql-test/include/wait_show_condition.inc: Bug #42419: new test macro to wait for a row in SHOW to have a certain value. mysql-test/r/innodb_bug42419.result: Bug #42419: test case mysql-test/r/innodb_mysql.result: Bug #42419: revert to the original innodb_mysql test mysql-test/t/innodb_bug42419.test: Bug #42419: test case mysql-test/t/innodb_mysql-master.opt: Bug #42419: revert to the original innodb_mysql test mysql-test/t/innodb_mysql.test: Bug #42419: revert to the original innodb_mysql test
-