- 09 Nov, 2009 2 commits
-
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
The prefix --skip- didn't work on 64 bit big endian machines because of how the value pointer was casted.
-
- 06 Nov, 2009 8 commits
-
-
Evgeny Potemkin authored
-
Evgeny Potemkin authored
When values of different types are compared they're converted to a type that allows correct comparison. This conversion is done for each comparison and takes some time. When a constant is being compared it's possible to cache the value after conversion to speedup comparison. In some cases (large dataset, complex WHERE condition with many type conversions) query might be executed 7% faster. A test case isn't provided because all changes are internal and isn't visible outside. The behavior of the Item_cache is changed to cache values on the first request of cached value rather than at the moment of storing item to be cached. A flag named value_cached is added to the Item_cache class. It's set to TRUE when cache holds the value of the last stored item. Function named cache_value() is added to the Item_cache class and derived classes. This function actually caches the value of the saved item. Item_cache_xxx::store functions now only store item to be cached and set value_cached flag to FALSE. Item_cache_xxx::val_xxx functions are changed to call cache_value function prior to returning cached value if value_cached is FALSE. The Arg_comparator::set_cmp_func function now calls cache_converted_constant to cache constants if they need a type conversion. The Item_cache::get_cache function is overloaded to allow setting of the cache type. The cache_converted_constant function is added to the Arg_comparator class. It checks whether a value can and should be cached and if so caches it.
-
Luis Soares authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
only const tables The problem was caused by two shortcuts in the optimizer that are inapplicable in the ROLLUP case. Normally in a case when only const tables are involved in a query, DISTINCT clause can be safely optimized away since there may be only one row produced by the join. Similarly, we don't need to create a temporary table to resolve DISTINCT/GROUP BY/ORDER BY. Both of these are inapplicable when the WITH ROLLUP modifier is present. Fixed by disabling the said optimizations for the WITH ROLLUP case.
-
- 04 Nov, 2009 6 commits
-
-
Timothy Smith authored
-
Timothy Smith authored
-
Timothy Smith authored
Just change mysql_foo to mysql_cv_foo for one cache-id variable name. There was only one bad variable name, present in 5.0 and 5.1, but not in the -pe branch.
-
Timothy Smith authored
-
Timothy Smith authored
-
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
-
- 05 Nov, 2009 2 commits
-
-
Davi Arnaut authored
-
If --log-bin is set to a directory name with the trailing 'FN_LIBCHAR', which will be '/' on Unix like systems, and '\\' on Windows like systems. the basename of the binlog is empty so that the created files named '.000001' and '.index'. It is not expected. The same thing happened to --log-bin-index, --relay-log and --relay-log-index options. To resolve the problem, in these cases the program should report an error and abort.
-
- 04 Nov, 2009 3 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Luis Soares authored
BUG#47983: rpl_extraColmaster_myisam failed in PB2 with "Found warnings!!" BUG 45214 fixed the case when get_master_version_and_clock function, used by the slave, would not report errors. The slave now detects them and if related to transient network failures, it prints some warnings and retries to connect. On the other hand, if not network related, it just gives up and fails. As such, sometimes, in PB2, the slave comes across some transient communication issues between master and slave, while calling get_master_version_and_clock, causing warnings print outs to the error log. Nevertheless, in such cases slave retries to connect, in which it succeeds, and the test case continues as it normally would. But then, at the end of a successful test run, MTR checks the error log, finds the unexpected warnings and considers them harmful. This causes MTR to report error and, consequently, PB2 to report a failing test. We fix this by adding to the global warnings suppress list the warnings related to transient network failures only, which are reported while in function get_master_version_and_clock.
-
- 03 Nov, 2009 19 commits
-
-
Timothy Smith authored
-
Timothy Smith authored
special chars This script failed when the user tried passwords with multiple spaces, \, # or ' characters. Now proper escaping and quoting is used in all contexts. This problem occurs in the Perl version of this script, too, so fix it in both places.
-
Timothy Smith authored
Remove a bash-ism (if ! ...).
-
Davi Arnaut authored
-
Davi Arnaut authored
-
Konstantin Osipov authored
Bug#41756 "Strange error messages about locks from InnoDB". In JT_EQ_REF (join_read_key()) access method, don't try to unlock rows in the handler, unless certain that a) they were locked b) they are not used. Unlocking of rows is done by the logic of the nested join loop, and is unaware of the possible caching that the access method may have. This could lead to double unlocking, when a row was unlocked first after reading into the cache, and then when taken from cache, as well as to unlocking of rows which were actually used (but taken from cache). Delegate part of the unlocking logic to the access method, and in JT_EQ_REF count how many times a record was actually used in the join. Unlock it only if it's usage count is 0. Implemented review comments.
-
Magnus Blåudd authored
-
Konstantin Osipov authored
Bug#41756 "Strange error messages about locks from InnoDB". In JT_EQ_REF (join_read_key()) access method, don't try to unlock rows in the handler, unless certain that a) they were locked b) they are not used. Unlocking of rows is done by the logic of the nested join loop, and is unaware of the possible caching that the access method may have. This could lead to double unlocking, when a row was unlocked first after reading into the cache, and then when taken from cache, as well as to unlocking of rows which were actually used (but taken from cache). Delegate part of the unlocking logic to the access method, and in JT_EQ_REF count how many times a record was actually used in the join. Unlock it only if it's usage count is 0. Implemented review comments.
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
- re-enabled main.innodb_bug44369; - re-enabled main.innodb_bug47777; - re-enabled innodb.innodb_information_schema.
-
Jorgen Loland authored
values return too many records WHERE clauses with "outer_value_list NOT IN subselect" were handled incorrectly if the outer value list contained multiple items where at least one of these could be NULL. The first outer record with NULL value was handled correctly, but if a second record with NULL value existed, the optimizer would choose to reuse the result it got on the last execution of the subselect. This is incorrect if the outer value list has multiple items. The fix is to make Item_in_optimizer::val_int (in item_cmpfunc.cc) reuse the result of the latest execution for NULL values only if all values in the outer_value_list are NULL.
-
Sergey Vojtovich authored
Detailed revision comments: r6126 | vasil | 2009-10-30 10:36:07 +0200 (Fri, 30 Oct 2009) | 45 lines branches/zip: Merge r6112:6125 from branches/5.1: (skipping r6122 and r6123, Jimmy says these are already present and need not be merged): ------------------------------------------------------------------------ r6122 | jyang | 2009-10-30 05:18:38 +0200 (Fri, 30 Oct 2009) | 7 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc M /branches/5.1/mysql-test/innodb_bug44369.result M /branches/5.1/mysql-test/innodb_bug44369.test M /branches/5.1/mysql-test/innodb_bug46000.result M /branches/5.1/mysql-test/innodb_bug46000.test branches/5.1: Chnage WARN_LEVEL_ERROR to WARN_LEVEL_WARN for push_warning_printf() call in innodb. Fix Bug#47233: Innodb calls push_warning(MYSQL_ERROR::WARN_LEVEL_ERROR) rb://170 approved by Marko. ------------------------------------------------------------------------ r6123 | jyang | 2009-10-30 05:43:06 +0200 (Fri, 30 Oct 2009) | 8 lines Changed paths: M /branches/5.1/os/os0proc.c branches/5.1: In os_mem_alloc_large(), if we fail to attach the shared memory, reset memory pointer ptr to NULL, and allocate memory from conventional pool. This is a port from branches/zip. Bug #48237 Error handling in os_mem_alloc_large appears to be incorrect rb://198 Approved by: Marko ------------------------------------------------------------------------ r6125 | vasil | 2009-10-30 10:31:23 +0200 (Fri, 30 Oct 2009) | 4 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc branches/5.1: White-space fixup. ------------------------------------------------------------------------
-
Sergey Vojtovich authored
Detailed revision comments: r6121 | sunny | 2009-10-30 01:42:11 +0200 (Fri, 30 Oct 2009) | 7 lines branches/zip: This test has been problematic for sometime now. The underlying bug is that the data dictionaries get out of sync. In the AUTOINC code we try and apply salve to the symptoms. In the past MySQL made some unrelated change and the dictionaries stopped getting out of sync and this test started to fail. Now, it seems they have reverted that changed and the test is passing again. I suspect this is not he last time that this test will change. r6124 | jyang | 2009-10-30 10:02:31 +0200 (Fri, 30 Oct 2009) | 5 lines branches/zip: Correct the bug number for -r6109 change from # 48273 to #48237
-
Sergey Vojtovich authored
Detailed revision comments: r6114 | vasil | 2009-10-29 18:43:51 +0200 (Thu, 29 Oct 2009) | 6 lines branches/zip: * Add ChangeLog entries for latest changes * Obey alphabetical order in the list of the files * White-space fixup
-
Sergey Vojtovich authored
Detailed revision comments: r6113 | vasil | 2009-10-29 18:15:50 +0200 (Thu, 29 Oct 2009) | 93 lines branches/zip: Merge r5912:6112 from branches/5.1: (after this merge the innodb-autoinc test starts to fail, but I commit anyway because it would be easier to investigate the failure this way) ------------------------------------------------------------------------ r5952 | calvin | 2009-09-22 19:45:07 +0300 (Tue, 22 Sep 2009) | 7 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc branches/5.1: fix bug#42383: Can't create table 'test.bug39438' For embedded server, MySQL may pass in full path, which is currently disallowed. It is needed to relax the condition by accepting full paths in the embedded case. Approved by: Heikki (on IM) ------------------------------------------------------------------------ r6032 | vasil | 2009-10-01 15:55:49 +0300 (Thu, 01 Oct 2009) | 8 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc branches/5.1: Fix Bug#38996 Race condition in ANALYZE TABLE by serializing ANALYZE TABLE inside InnoDB. Approved by: Heikki (rb://175) ------------------------------------------------------------------------ r6045 | jyang | 2009-10-08 02:27:08 +0300 (Thu, 08 Oct 2009) | 7 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc A /branches/5.1/mysql-test/innodb_bug47777.result A /branches/5.1/mysql-test/innodb_bug47777.test branches/5.1: Fix bug #47777. Treat the Geometry data same as Binary BLOB in ha_innobase::store_key_val_for_row(), since the Geometry data is stored as Binary BLOB in Innodb. Review: rb://180 approved by Marko Makela. ------------------------------------------------------------------------ r6051 | sunny | 2009-10-12 07:05:00 +0300 (Mon, 12 Oct 2009) | 6 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc M /branches/5.1/mysql-test/innodb-autoinc.result M /branches/5.1/mysql-test/innodb-autoinc.test branches/5.1: Ignore negative values supplied by the user when calculating the next value to store in dict_table_t. Setting autoincrement columns top negative values is undefined behavior and this change should bring the behavior of InnoDB closer to what users expect. Added several tests to check. rb://162 ------------------------------------------------------------------------ r6052 | sunny | 2009-10-12 07:09:56 +0300 (Mon, 12 Oct 2009) | 4 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc M /branches/5.1/mysql-test/innodb-autoinc.result M /branches/5.1/mysql-test/innodb-autoinc.test branches/5.1: Reset the statement level autoinc counter on ROLLBACK. Fix the test results too. rb://164 ------------------------------------------------------------------------ r6053 | sunny | 2009-10-12 07:37:49 +0300 (Mon, 12 Oct 2009) | 6 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc M /branches/5.1/mysql-test/innodb-autoinc.result M /branches/5.1/mysql-test/innodb-autoinc.test branches/5.1: Copy the maximum AUTOINC value from the old table to the new table when MySQL does a CREATE INDEX ON T. This is required because MySQL does a table copy, rename and drops the old table. Fix Bug#47125: auto_increment start value is ignored if an index is created and engine=innodb rb://168 ------------------------------------------------------------------------ r6076 | vasil | 2009-10-14 19:30:12 +0300 (Wed, 14 Oct 2009) | 4 lines Changed paths: M /branches/5.1/row/row0mysql.c branches/5.1: Fix typo. ------------------------------------------------------------------------
-
Sergey Vojtovich authored
Detailed revision comments: r6112 | calvin | 2009-10-29 16:21:15 +0200 (Thu, 29 Oct 2009) | 4 lines branches/zip: consideration for icc compilers Proposed by MySQL, and approved by Marko.
-
Sergey Vojtovich authored
Detailed revision comments: r6110 | marko | 2009-10-29 12:44:57 +0200 (Thu, 29 Oct 2009) | 2 lines branches/zip: Makefile.am (INCLUDES): Merge a change from MySQL: Use $(srcdir)/include instead of $(top_srcdir)/storage/innobase/include. r6111 | marko | 2009-10-29 13:04:11 +0200 (Thu, 29 Oct 2009) | 33 lines branches/zip: Fix corruption of buf_pool->LRU_old and improve debug assertions. This was reported as Issue #381. buf_page_set_old(): Assert that blocks may only be set old if buf_pool->LRU_old is initialized and buf_pool->LRU_old_len is nonzero. Assert that buf_pool->LRU_old points to the block at the old/new boundary. buf_LRU_old_adjust_len(): Invoke buf_page_set_old() after adjusting buf_pool->LRU_old and buf_pool->LRU_old_len, in order not to violate the added assertions. buf_LRU_old_init(): Replace buf_page_set_old() with a direct assignment to bpage->old, because these loops that initialize all the blocks would temporarily violate the assertions about buf_pool->LRU_old. buf_LRU_remove_block(): When setting buf_pool->LRU_old = NULL, also clear all bpage->old flags and set buf_pool->LRU_old_len = 0. buf_LRU_add_block_to_end_low(), buf_LRU_add_block_low(): Move the buf_page_set_old() call later in order not to violate the debug assertions. If buf_pool->LRU_old is NULL, set old=FALSE. buf_LRU_free_block(): Replace the UNIV_LRU_DEBUG assertion with a dummy buf_page_set_old() call that performs more thorough checks. buf_LRU_validate(): Do not tolerate garbage in buf_pool->LRU_old_len even if buf_pool->LRU_old is NULL. Check that bpage->old is monotonic. buf_relocate(): Make the UNIV_LRU_DEBUG checks stricter. buf0buf.h: Revise the documentation of buf_page_t::old and buf_pool_t::LRU_old_len.
-