- 31 Jan, 2013 1 commit
-
-
unknown authored
Analysis: Range analysis discoveres that the query can be executed via loose index scan for GROUP BY. Later, GROUP BY analysis fails to confirm that the GROUP operation can be computed via an index because there is no logic to handle duplicate field references in the GROUP clause. As a result the optimizer produces an inconsistent plan. It constructs a temporary table, but on the other hand the group fields are not set to point there. Solution: Make loose scan analysis work in sync with order by analysis. In the case of duplicate columns loose scan will not be applicable. This limitation will be lifted in 10.0 by removing duplicate columns.
-
- 25 Jan, 2013 2 commits
-
-
Sergei Golubchik authored
MDEV-729 lp:998028 - Server crashes on normal shutdown in closefrm after executing a query from MyISAM table don't write a key value into the record buffer - a key length can be larger then the record length.
-
Sergei Golubchik authored
MDEV-759 lp:998340 - Valgrind complains on simple selects containing expression DAY(FROM_UNIXTIME(-1)) check item->null_value before using the result of item->val_int()
-
- 21 Jan, 2013 3 commits
-
-
Igor Babaev authored
-
Igor Babaev authored
This bug could result in returning 0 for the expressions of the form <aggregate_function>(distinct field) when the system variable max_heap_table_size was set to a small enough number. It happened because the method Unique::walk() did not support the case when more than one pass was needed to merge the trees of distinct values saved in an external file. Backported a fix in grant_lowercase.test from mariadb 5.5.
-
Sergei Golubchik authored
MDEV-4029 SELECT on information_schema using a subquery locks up the information_schema table due to incorrect mutexes handling Early evaluation of subqueries in the WHERE conditions on I_S.*_STATUS tables, otherwise the subquery on this same table will try to acquire LOCK_status twice.
-
- 09 Jan, 2013 1 commit
-
-
Sergei Golubchik authored
-
- 07 Dec, 2012 1 commit
-
-
Joerg Bruehe authored
taking a change done to main 5.1 by Dmitri Lenev. This is the original comment: > committer: Dmitry Lenev <Dmitry.Lenev@oracle.com> > branch nick: mysql-5.1-15954896 > timestamp: Wed 2012-12-05 19:26:56 +0400 > message: > Bug #15954896 "SP, MULTI-TABLE DELETE AND LONG ALIAS". Using too long table aliases in stored routines might have caused server crashes. Code in sp_head::merge_table_list() which is responsible for collecting information about tables used in stored routine was not aware of the fact that table alias might have arbitrary length. I.e. it assumed that table alias can't be longer than NAME_LEN bytes and allocated buffer for a key identifying table accordingly. This patch fixes the issue by ensuring that we use dynamically allocated buffer for table key when table alias is too long. By default stack based buffer is used in which NAME_LEN bytes are reserved for table alias.
-
- 04 Dec, 2012 1 commit
-
-
Sergei Golubchik authored
-
- 21 Dec, 2012 1 commit
-
-
Vladislav Vaintroub authored
-
- 05 Dec, 2012 1 commit
-
-
Vladislav Vaintroub authored
The failure is caused by failing stat() call . C Runtime function stat() uses old struct with 32bit st_size member, and since Visual Studio 2010 , it returns an error on st_size overflow (i.e on files larger than 4GB) Fix replaces stat() by my_stat(), the later is backed by 64bit-able stat64().
-
- 29 Nov, 2012 1 commit
-
-
unknown authored
-
- 22 Nov, 2012 1 commit
-
-
Vladislav Vaintroub authored
-
- 20 Nov, 2012 1 commit
-
-
unknown authored
Fix some problems in the TC_LOG_MMAP commit processing, which could lead to assertions in some cases. Problems are mostly reproducible in MariaDB 10.0 with asynchroneous commit checkpoints, but most of the problems were present in earlier versions also.
-
- 19 Nov, 2012 1 commit
-
-
Sergei Golubchik authored
-
- 17 Nov, 2012 1 commit
-
-
Sergei Golubchik authored
-
- 12 Nov, 2012 1 commit
-
-
Sergei Golubchik authored
followup fixes for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN
-
- 10 Nov, 2012 1 commit
-
-
Vladislav Vaintroub authored
Take into account that length of strings passed down to this function can be up to FN_REFLEN+1 bytes. including terminating zero. The overwrite was caused by incomplete fix to MySQL Bug # 44834
-
- 09 Nov, 2012 1 commit
-
-
Sergei Golubchik authored
add a test case for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN
-
- 07 Nov, 2012 1 commit
-
-
unknown authored
-
- 06 Nov, 2012 1 commit
-
-
unknown authored
-
- 01 Nov, 2012 3 commits
-
-
Tor Didriksen authored
Add missing DBUG_RETURNs, otherwise the debug-stack gets messed up, and _db_enter_ and _db_exit_ will access data outside the current stack frame.
-
unknown authored
-
unknown authored
-
- 31 Oct, 2012 2 commits
-
-
Michael Widenius authored
mysql-test/r/partition.result: Added test case mysql-test/t/partition.test: Added test case sql/ha_partition.cc: Removed printing of not initialized variable storage/maria/ha_maria.cc: Don't copy variables that are not initialized
-
Michael Widenius authored
storage/maria/ma_test2.c: Problem was that rnd() generated bigger value than allocated array
-
- 30 Oct, 2012 2 commits
-
-
Anirudh Mangipudi authored
TO 'MYISAM_SORT_BUFFER_SIZE' Problem: 'myisam_sort_buffer_size' is a parameter used by mysqld program only whereas 'sort_buffer_size' is used by mysqld and myisamchk programs. But the error message printed when myisamchk program is run with insufficient buffer size is myisam_sort_buffer_size is too small which may mislead to the server parameter myisam_sort_buffer_size. SOLUTION: A parameter 'myisam_sort_buffer_size' is added as an alias for 'sort_buffer_size' and the 'sort_buffer_size' parameter is marked as deprecated. So myisamchk also has both the parameters with the same role.
-
Shivji Kumar Jha authored
main.mysqlbinlog_row_innodb are skipped by mtr === Problem === The following tests are wrongly placed in main suite and as a result these are not run with proper binlog format combinations. Some are always skipped by mtr. 1) mysqlbinlog_row_myisam 2) mysqlbinlog_row_innodb 3) mysqlbinlog_row.test 4) mysqlbinlog_row_trans.test 5) mysqlbinlog-cp932 6) mysqlbinlog2 7) mysqlbinlog_base64 === Background === mtr runs the tests placed in main suite with binlog format=stmt. Those that need to be tested against binlog format=row or mixed or more than one binlog format and require only one mysql server are placed in binlog suite. mtr runs tests in binlog suite with all three binlog formats(stmt,row and mixed). === Fix === 1) Moved the test listed in problem section above to binlog suite. 2) Added prefix "binlog_" to the name of each test case moved. Renamed the coresponding result files and option files accordingly. mysql-test/extra/binlog_tests/mysqlbinlog_row_engine.inc: include file for mysqlbinlog_row_myisam.test and mysqlbinlog_row_myisam.test which are being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog-cp932.result: result file for mysqlbinlog-cp932.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog2.result: result file for mysqlbinlog2.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_base64.result: result file for mysqlbinlog_base64.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row.result: result file for mysqlbinlog_row.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_innodb.result: result file for mysqlbinlog_row_innodb.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_myisam.result: result file for mysqlbinlog_row_myisam.test which is being moved to binlog suite. mysql-test/suite/binlog/r/binlog_mysqlbinlog_row_trans.result: result file for mysqlbinlog_row_trans.test which is being moved to binlog suite. mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932-master.opt: option file for mysqlbinlog-cp932.test which is being moved to binlog suite. mysql-test/suite/binlog/t/binlog_mysqlbinlog-cp932.test: the test requires binlog format=stmt or mixed. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was never run with binlog format=mixed. mysql-test/suite/binlog/t/binlog_mysqlbinlog2.test: the test requires binlog format=stmt or mixed. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was never run with binlog format=mixed. mysql-test/suite/binlog/t/binlog_mysqlbinlog_base64.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_innodb.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_myisam.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr. mysql-test/suite/binlog/t/binlog_mysqlbinlog_row_trans.test: the test requires binlog format=row. Since, it was placed in main suite earlier, it was only run with binlog format=stmt, and hence this test was always skipped by mtr.
-
- 29 Oct, 2012 2 commits
-
-
unknown authored
No commit message
-
Alexander Nozdrin authored
-
- 22 Oct, 2012 1 commit
-
-
Marko Mäkelä authored
IN ALTER TABLE ... ADD UNIQUE KEY A bogus debug assertion failure occurred when reporting a duplicate key on a column prefix of a CHAR column. This is a regression from Bug#14729221 IN-PLACE ALTER TABLE REPORTS '' INSTEAD OF REAL DUPLICATE VALUE FOR PREFIX KEYS. The assertion is only present when UNIV_DEBUG is defined (which it is in debug builds starting from MySQL 5.5). It is a case of overasserting. Fix approved by Inaam Rana on IM.
-
- 21 Oct, 2012 2 commits
-
-
Nuno Carvalho authored
Moved explicit instantiation of available_buffer and valid_buffer_range template functions to sql/log_event.cc.
-
Nuno Carvalho authored
Merge bundle on mysql-5.1.
-
- 19 Oct, 2012 1 commit
-
-
Joerg Bruehe authored
-
- 18 Oct, 2012 2 commits
-
-
Neeraj Bisht authored
Problem:- When we execute a query which has subquery with GROUP BY, ORDER BY and have a BLOB column,results a memory leak. Analysis:- In case of subquery, which have GROUP BY on BLOB and a ORDER BY on other field and BLOB is not a key. We allocate a tmp buffer to copy_field to take care of BLOB value.This copy_field value can have copies of its in two join(objects), so while freeing this copy_field we have to take care that it is not deleted twice. The double deletion of tmp_table_param.copy_field is handled by two patches. One by Kostja : revid:sp1r-konstantin@mysql.com-20050627101056-55153 Fix the broken test suite in -debug build. and other by Oleksandr revid:sp1r-bell@sanja.is.com.ua-20060118114857-19905 Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851). both of this patches are commited in different branch and while merging they both get placed,but there is no need for Kostja patch as Oleksandr patch handle this. sql/sql_select.cc: Bug13726751, tmp_join clean up is not necessary as later in the code we are taking care of cleaning up of tmp_join copy_field.
-
Marko Mäkelä authored
LEN <= SIZEOF(ULONGLONG) This bug was caught in the WL#6255 ALTER TABLE...ADD COLUMN in MySQL 5.6, but there is a bug in all InnoDB versions that support auto-increment columns. row_search_autoinc_read_column(): When reading the maximum value of the auto-increment column, and the column only contains NULL values, return 0. This corresponds to the case when the table is empty in row_search_max_autoinc(). rb:1415 approved by Sunny Bains
-
- 17 Oct, 2012 4 commits
-
-
-
Tatjana Azundris Nuernberg authored
mysqld_safe script did not heed MySQL specific environment variable $UMASK, leading to divergent behavior between mysqld and mysqld_safe. Patch adds an approximation of mysqld's behavior to mysqld_safe, within the bounds dictated by attempt to have mysqld_safe run on even the most basic of shells (proper '70s sh, not just bash with a fancy symlink). Patch also adds approximation of said behavior to mysqld_multi (in perl). (backport)
-
Yasufumi Kinoshita authored
rb://1334 approved by: Inaam Rana
-
Tatjana Azundris Nuernberg authored
mysqld_safe script did not heed MySQL specific environment variable $UMASK, leading to divergent behavior between mysqld and mysqld_safe. Patch adds an approximation of mysqld's behavior to mysqld_safe, within the bounds dictated by attempt to have mysqld_safe run on even the most basic of shells (proper '70s sh, not just bash with a fancy symlink). Patch also adds approximation of said behavior to mysqld_multi (in perl).
-