- 31 Oct, 2012 1 commit
-
-
unknown authored
- Ensure asm parameters are in registers, so we do not de-reference from bogus stack pointer. - Make return address undefined in DWARF unwind info in my_context_spawn, so DWARF-based unwinders will know this is the end of the call stack (same as the amd64 fix for the similar issue).
-
- 30 Oct, 2012 2 commits
-
-
Vladislav Vaintroub authored
Disable compiling unit tests if WITH_UNIT_TEST is FALSE. Also, fix CMake code to allow compilation WITHOUT_ARIA_STORAGE_ENGINE
-
Vladislav Vaintroub authored
Changed implementation os_file_rename() on Windows such as it does not fail if destination file already exists. Now MoveFileEx() with MOVEFILE_REPLACE_EXISTING flag is used, instead of prior MoveFile(). This fixed implementation is better compatible with rename() on POSIX systems.
-
- 26 Oct, 2012 1 commit
-
-
unknown authored
This patch undoes the removal of enum store_key_result by the previous patch for mdev-3812.
-
- 25 Oct, 2012 1 commit
-
-
unknown authored
MDEV-3812: Remove unneeded extra call to engine->exec() in Item_subselect::exec, remove enum store_key_result This task fixes an ineffeciency that is a remainder from MySQL 5.0/5.1. There, subqueries were optimized in a lazy manner, when executed for the first time. During this lazy optimization it may happen that the server finds a more efficient subquery engine, and substitute the current engine of the query being executed with the new engine. This required re-execution of the engine. MariaDB 5.3 pre-optimizes subqueries in almost all cases, and the engine is chosen in most cases, except when subquery materialization found that it must use partial matching. In this case, the current code was performing one extra re-execution although it was not needed at all. The patch performs the re-execution only if the engine was changed while executing. In addition the patch performs small cleanup by removing "enum store_key_result" because it is essentially a boolean, and the code that uses it already maps it to a boolean.
-
- 19 Oct, 2012 1 commit
-
-
Sergei Golubchik authored
-
- 18 Oct, 2012 3 commits
-
-
Sergei Golubchik authored
-
Vladislav Vaintroub authored
do not print return address when callstack is output on Windows, it does not provide any useful info
-
Vladislav Vaintroub authored
Do not DBUG_PRINT uninitialized variable. This avoid false positive from runtime checks in debug builds (Windows).
-
- 17 Oct, 2012 1 commit
-
-
Sergei Golubchik authored
shared should provide libmysqlclient.so.18(libmysqlclient_16) too don't "use DBD::mysql" explicitly in mytop
-
- 16 Oct, 2012 4 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
don't try to define it for plugins, then, as they don't need it.
-
- 12 Oct, 2012 4 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
unknown authored
Fix by Sergey Petrunia. This patch only prevents the evaluation of expensive subqueries during optimization. The crash reported in this bug has been fixed by some other patch. The fix is to call value->is_null() only when !value->is_expensive(), because is_null() may trigger evaluation of the Item, which in turn triggers subquery evaluation if the Item is a subquery.
-
unknown authored
In 10.0, VIO timeouts can be in milliseconds, so we add a new function mysql_get_timeout_value_ms() which can return millisecond-precision timeout values. In 5.5, we do not have millisecond precision for timeouts. But we still provide the mysql_get_timeout_value_ms() function; this makes it easier for applications as they can use the millisecond function in 10.0 and still work with the 5.5 version of the client library.
-
- 11 Oct, 2012 1 commit
-
-
unknown authored
MySQL fix for bug#11765413 removed (we have better and more general fix for the problem). Test suite added.
-
- 10 Oct, 2012 2 commits
-
-
unknown authored
Find left table in right join (which turned to left join by reordering tables in join list but phisical order of tables of SELECT left as it was).
-
Sergey Petrunya authored
.. into MariaDB 5.3 Fix for Bug#12667154 SAME QUERY EXEC AS WHERE SUBQ GIVES DIFFERENT RESULTS ON IN() & NOT IN() COMP #3 This bug causes a wrong result in mysql-trunk when ICP is used and bad performance in mysql-5.5 and mysql-trunk. Using the query from bug report to explain what happens and causes the wrong result from the query when ICP is enabled: 1. The t3 table contains four records. The outer query will read these and for each of these it will execute the subquery. 2. Before the first execution of the subquery it will be optimized. In this case the important is what happens to the first table t1: -make_join_select() will call the range optimizer which decides that t1 should be accessed using a range scan on the k1 index It creates a QUICK_RANGE_SELECT object for this. -As the last part of optimization the ICP code pushes the condition down to the storage engine for table t1 on the k1 index. This produces the following information in the explain for this table: 2 DEPENDENT SUBQUERY t1 range k1 k1 5 NULL 3 Using index condition; Using filesort Note the use of filesort. 3. The first execution of the subquery does (among other things) due to the need for sorting: a. Call create_sort_index() which again will call find_all_keys(): b. find_all_keys() will read the required keys for all qualifying rows from the storage engine. To do this it checks if it has a quick-select for the table. It will use the quick-select for reading records. In this case it will read four records from the storage engine (based on the range criteria). The storage engine will evaluate the pushed index condition for each record. c. At the end of create_sort_index() there is code that cleans up a lot of stuff on the join tab. One of the things that is cleaned is the select object. The result of this is that the quick-select object created in make_join_select is deleted. 4. The second execution of the subquery does the same as the first but the result is different: a. Call create_sort_index() which again will call find_all_keys() (same as for the first execution) b. find_all_keys() will read the keys from the storage engine. To do this it checks if it has a quick-select for the table. Now there is NO quick-select object(!) (since it was deleted in step 3c). So find_all_keys defaults to read the table using a table scan instead. So instead of reading the four relevant records in the range it reads the entire table (6 records). It then evaluates the table's condition (and here it goes wrong). Since the entire condition has been pushed down to the storage engine using ICP all 6 records qualify. (Note that the storage engine will not evaluate the pushed index condition in this case since it was pushed for the k1 index and now we do a table scan without any index being used). The result is that here we return six qualifying key values instead of four due to not evaluating the table's condition. c. As above. 5. The two last execution of the subquery will also produce wrong results for the same reason. Summary: The problem occurs due to all but the first executions of the subquery is done as a table scan without evaluating the table's condition (which is pushed to the storage engine on a different index). This is caused by the create_sort_index() function deleting the quick-select object that should have been used for executing the subquery as a range scan. Note that this bug in addition to causing wrong results also can result in bad performance due to executing the subquery using a table scan instead of a range scan. This is an issue in MySQL 5.5. The fix for this problem is to avoid that the Quick-select-object that the optimizer created is deleted when create_sort_index() is doing clean-up of the join-tab. This will ensure that the quick-select object and the corresponding pushed index condition will be available and used by all following executions of the subquery.
-
- 08 Oct, 2012 1 commit
-
-
Sergei Golubchik authored
-
- 05 Oct, 2012 2 commits
-
-
Sergei Golubchik authored
cmake/cpack_rpm.cmake: * mark all cnf files with %config(noreplace) * add the forgotten postun script sql/sys_vars.cc: 0 for a string variable means "no default. But datadir has the default value. support-files/rpm/server-postin.sh: * use mysqld --help to determine the correct datadir in the presence of my.cnf files (better than my_print_defaults, because it considers the correct group set). * Only create users, and chown/chmod if it's a fresh install, not an upgrade. * only run mysql_install_db if datadir does not exist
-
unknown authored
The problem was in incorrect detection of merged views in tem_direct_view_ref::used_tables() .
-
- 02 Oct, 2012 1 commit
-
-
Igor Babaev authored
-
- 01 Oct, 2012 2 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
- 08 Oct, 2012 1 commit
-
-
unknown authored
Do not include mytop in mariadb-client-5.5 .deb package. There is already a Debian mytop package, so we get a package conflict. And there is no reason for the MariaDB project to guerrilla-take-over mytop maintenance.
-
- 04 Oct, 2012 1 commit
-
-
Michael Widenius authored
- Wrong thd uses in Item_subselect, could lead to crash - Inititalize uninitialized variable in new autoincrement handling code sql/handler.cc: More DBUG_PRINT sql/item_subselect.cc: Wrong thd uses in Item_subselect, could lead to crash storage/innobase/handler/ha_innodb.cc: Initialize variable needed by upper level. This only happens when auto-increment value wraps over. storage/xtradb/handler/ha_innodb.cc: Initialize variable needed by upper level. This only happens when auto-increment value wraps over.
-
- 02 Oct, 2012 1 commit
-
-
Michael Widenius authored
- Don't abort if plugin table exists - Use longer timeout for start/stop of mysqld debian/dist/Debian/mariadb-server-5.5.postinst: Don't abort if plugin table exists debian/mariadb-server-5.5.mysql.init: Use longer timeout for start/stop of mysqld
-
- 01 Oct, 2012 1 commit
-
-
Sergei Golubchik authored
-
- 30 Sep, 2012 1 commit
-
-
Igor Babaev authored
In some rare cases when the value of the system variable join_buffer_size was set to a number less than 256 the function JOIN_CACHE::set_constants determined the size of an offset in the join buffer equal to 1 though the minimal join buffer required more than 256 bytes. This could cause a crash of the server when records from the join buffer were read.
-
- 28 Sep, 2012 1 commit
-
-
unknown authored
-
- 27 Sep, 2012 4 commits
-
-
Sergei Golubchik authored
-
unknown authored
-
unknown authored
-
Alexey Botchkov authored
The feature was backported from MySQL 5.6. Some code was added to make commands as SELECT * FROM ignored_db.t1; CALL ignored_db.proc(); USE ignored_db; to take that option into account. per-file comments: mysql-test/r/ignore_db_dirs_basic.result test result added. mysql-test/t/ignore_db_dirs_basic-master.opt options for the test, actually the set of --ignore-db-dir lines. mysql-test/t/ignore_db_dirs_basic.test test for the feature. Same test from 5.6 was taken as a basis, then tests for SELECT, CALL etc were added. per-file comments: sql/mysql_priv.h MDEV-495 backport --ignore-db-dir. interface for db_name_is_in_ignore_list() added. sql/mysqld.cc MDEV-495 backport --ignore-db-dir. --ignore-db-dir handling. sql/set_var.cc MDEV-495 backport --ignore-db-dir. the @@ignore_db_dirs variable added. sql/sql_show.cc MDEV-495 backport --ignore-db-dir. check if the directory is ignored. sql/sql_show.h MDEV-495 backport --ignore-db-dir. interface added for opt_ignored_db_dirs. sql/table.cc MDEV-495 backport --ignore-db-dir. check if the directory is ignored.
-
- 26 Sep, 2012 3 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
unknown authored
- Fix some warnings in newer GCC (-Werror ...). - Fix wrong STACK_DIRECTION detected by configure due to compiler inlining.
-