- 26 Dec, 2009 2 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
- 24 Dec, 2009 2 commits
-
-
Luis Soares authored
-
Luis Soares authored
to make the test run gracefully on windows. There was also a syntax error in windows part of the test.
-
- 22 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
Several problems fixed : 1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of fields quoted by these expressions pointing to the already freed temporary table used to calculate the UNION. Fixed by correctly cleaning up expressions of any depth. 2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED execution. Fixed by not doing the transformation when in EXPLAIN. 3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized UNION that gets "promoted" to be valid for the whole union, e.g. SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE). This is a case that demonstrates a more general problem of parts of the query being moved to another level. When doing such transformation late in the optimization run when most of the flags about the contents of the query are already aggregated it's possible to "split" the flags so that they correctly reflect the new queries after the transformation. In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY that we're to move to the UNION level and what part is about the other parts of the second SELECT. Fixed by throwing and error when such statements are about to be processed by adding a check for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION. To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real global ORDER BY for the UNION outside of the parenthesis.
-
- 24 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
-
- 22 Dec, 2009 1 commit
-
-
Ramil Kalimullin authored
on re-execution of prepared statement Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization is called before each PS execution. However, we don't properly initialize its stucture every time before the call. Fix: properly initialize the sturture used.
-
- 21 Dec, 2009 1 commit
-
-
Serge Kozlov authored
-
- 18 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
freezes (win) the server The check for equality was assuming the field object is always created. If it's not it was de-referencing a NULL pointer. Fixed to use the data in the create object instead.
-
- 24 Dec, 2009 4 commits
-
-
Satya B authored
-
Satya B authored
the declaration of THR_LOCK_myisam_mmap in mi_static is redundant as it accessible via the extern declaration in include/myisam.h
-
Luis Soares authored
-
Luis Soares authored
-
- 23 Dec, 2009 3 commits
-
-
Sergey Glukhov authored
If first call of the procedure is failed on the open_table stage stmt_arena->state is set to EXECUTED state. On second call(if no errors on open_table stage) it leads to use of worng memory arena in find_field_in_view() function as thd->stmt_arena->is_stmt_prepare_or_first_sp_execute() returns FALSE for EXECUTED state. The item is created not in its own arena and it leads to crash on further calls of the procedure. The fix: change state of arena only if no errors on open_table stage happens.
-
Satya B authored
-
Satya B authored
and also applying 5.1-ss6355 Detailed revision comments: r6324 | jyang | 2009-12-17 06:54:24 +0200 (Thu, 17 Dec 2009) | 8 lines branches/5.1: Fix bug #47814 - Diagnostics are frequently not printed after a long lock wait in InnoDB. Separate out the lock wait timeout check thread from monitor information printing thread. rb://200 Approved by Marko. r6349 | marko | 2009-12-22 11:09:54 +0200 (Tue, 22 Dec 2009) | 3 lines branches/5.1: lock_print_info_summary(): Remove a reference to innobase_mysql_end_print_arbitrary_thd() that should have been removed in r6347 when removing the function. r6350 | marko | 2009-12-22 11:11:09 +0200 (Tue, 22 Dec 2009) | 1 line branches/5.1: Remove an obsolete declaration of LOCK_thread_count.
-
- 22 Dec, 2009 4 commits
-
-
Satya B authored
-
Satya B authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
At the end of execution top level join execution we cleanup this join with true argument. It leads to underlying join cleanup(subquery) with true argument too and to tmp_table_param->field array cleanup which is required later. The problem is that Item_func_set_user_var does not set result_filed which leads to unnecessary repeated excution of subquery on final stage. The fix is to set result_field for Item_func_set_user_var.
-
- 21 Dec, 2009 4 commits
-
-
Mattias Jonsson authored
-
Satya B authored
not address the printouts issue Detailed revision comments: r6310 | marko | 2009-12-15 15:23:54 +0200 (Tue, 15 Dec 2009) | 30 lines branches/5.1: Merge r4922 from branches/zip. This the fix for the first part of Bug #41609 from InnoDB Plugin to the built-in InnoDB in MySQL 5.1. This allows InnoDB Hot Backup to back up a database while the built-in InnoDB in MySQL 5.1 is creating temporary tables. (This fix does not address the printouts about missing .ibd files for temporary tables at InnoDB startup, which was committed to branches/zip in r6252.) rb://219 approved by Sunny Bains. branches/zip: Distinguish temporary tables in MLOG_FILE_CREATE. This addresses Mantis Issue #23 in InnoDB Hot Backup and some of MySQL Bug #41609. In MLOG_FILE_CREATE, we need to distinguish temporary tables, so that InnoDB Hot Backup can work correctly. It turns out that we can do this easily, by using a bit of the previously unused parameter for page number. (The page number parameter of MLOG_FILE_CREATE has been written as 0 ever since MySQL 4.1, which introduced MLOG_FILE_CREATE.) MLOG_FILE_FLAG_TEMP: A flag for indicating a temporary table in the page number parameter of MLOG_FILE_ operations. fil_op_write_log(): Add the parameter log_flags. fil_op_log_parse_or_replay(): Add the parameter log_flags. Do not replay MLOG_FILE_CREATE when MLOG_FILE_FLAG_TEMP is set in log_flags. This only affects ibbackup --apply-log. InnoDB itself never replays file operations.
-
Satya B authored
Detailed revision comments: r6306 | calvin | 2009-12-14 15:12:46 +0200 (Mon, 14 Dec 2009) | 5 lines branches/5.1: fix bug#49267: innodb-autoinc.test fails on windows because of different case mode There is no change to the InnoDB code, only to fix test case by changing "T1" to "t1".
-
He Zhenxing authored
When the $diff_statement variable for diff_master_slave.inc was put in multiple lines, the rear part of the statement would be missing when being executed on Windows systems. Fixed the problem by always putting the value for $diff_statement in one line.
-
- 20 Dec, 2009 1 commit
-
-
Staale Smedseng authored
unnecessarily Changing an instance of the define that was missed in the original commit due to the fact that it was misspelled.
-
- 18 Dec, 2009 4 commits
-
-
Davi Arnaut authored
Post-merge fix: wait for statement result before disconnecting. Otherwise, the statement might affect unrelated tests.
-
Davi Arnaut authored
MySQL 5.1 specific fixes.
-
Davi Arnaut authored
-
Magne Mahre authored
Bug#35589 SET PASSWORD caused a crash Bug#35591 FLUSH PRIVILEGES caused a crash A race condition on the privilege hash tables (proc_priv_hash and func_priv_hash) caused one thread to try to delete elements that had already been deleted by another thread. The bug was caused by reading and saving the pointers to the hash tables outside mutex protection. This led to an inconsistency where a thread copied a pointer to a hash, another thread did the same, the first thread then deleted the hash, and the second then crashed when it in turn tried to delete the deleted hash. The fix is to ensure that operations on the shared hash structures happens under mutex protection (moving the locking up a little)
-
- 17 Dec, 2009 11 commits
-
-
Jim Winstead authored
-
Jim Winstead authored
-
Davi Arnaut authored
The problem is a somewhat common misusage of the strmake function. The strmake(dst, src, len) function writes at most /len/ bytes to the string pointed to by src, not including the trailing null byte. Hence, if /len/ is the exact length of the destination buffer, a one byte buffer overflow can occur if the length of the source string is equal to or greater than /len/.
-
Alfranio Correia authored
-
Andrei Elkin authored
-
Andrei Elkin authored
The test allowed random coincidence of connection ids for two concurrent sessions performing CREATE/DROP temp tables. Fixed with correcting the test. The sessions connection ids are not changed from their defaults anymore.
-
Satya B authored
-
Satya B authored
-
Satya B authored
When compressed myisam files are opened, they are always memory mapped sometimes causing memory swapping problems. When we mmap the myisam compressed tables of size greater than the memory available, the kswapd0 process utilization is very high consuming 30-40% of the cpu. This happens only with linux kernels older than 2.6.9 With newer linux kernels, we don't have this problem of high cpu consumption and this option may not be required. The option 'myisam_mmap_size' is added to limit the amount of memory used for memory mapping of myisam files. This option is not dynamic. The default value on 32 bit system is 4294967295 bytes and on 64 bit system it is 18446744073709547520 bytes. Note: Testcase only tests the option variable. The actual bug has be to tested manually.
-
Martin Hansson authored
returns incorrect results with where An outer join of a const table (outer) and a normal table (inner) with GROUP BY on a field from the outer table would optimize away GROUP BY, and thus trigger the optimization to do away with a temporary table if grouping was performed on columns from the const table, hence executing the query with filesort without temporary table. But this should not be done if there is a non-indexed access to the inner table, since filesort does not handle joins. It expects either ref access, range ditto or table scan. The join condition will thus not be applied. Fixed by always forcing execution with temporary table in the case of ROLLUP with a query involving an outer join. This is a slightly broader class of queries than need fixing, but it is hard to ascertain the position of a ROLLUP field wrt outer join with current query representation.
-
Ramil Kalimullin authored
-