An error occurred fetching the project authors.
- 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.
-
- 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.
-
- 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.
-
- 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.
-
- 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.
-
- 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.
-
- 04 Jun, 2009 1 commit
-
-
Georgi Kodinov authored
When copying the Item class one must copy its attributes as well.
-
- 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).
-
- 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.
-
- 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.
-
Ramil Kalimullin authored
Problem: commit doesn't delete savepoints if there are no changes in the transaction. Fix: delete them in such cases.
-
- 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
-
- 19 Feb, 2009 1 commit
-
-
Georgi Kodinov authored
connections The problem is that tables can enter open table cache for a thread without being properly cleaned up. This can happen if make_join_statistics() fails to read a const table because of e.g. a deadlock. It does set a member of TABLE structure to a value it allocates, but doesn't clean-up this setting on error nor does it set the rest of the members in JOIN to allow for automatic cleanup. As a result when such an error occurs and the next statement depends re-uses the table from the open tables cache it will get it with this TABLE::reginfo.join_tab pointing to a memory area that's freed. Fixed by making sure make_join_statistics() cleans up TABLE::reginfo.join_tab on error.
-
- 09 Jan, 2009 1 commit
-
-
Davi Arnaut authored
The special TRUNCATE TABLE (DDL) transaction wasn't being properly rolled back if a error occurred during row by row deletion. The error can be caused by a foreign key restriction imposed by InnoDB SE and would cause the server to erroneously issue a implicit commit. The solution is to rollback the transaction if a truncation via row by row deletion fails, otherwise commit. All effects of a TRUNCATE ABLE operation are rolled back if a row by row deletion fails.
-
- 07 Jan, 2009 1 commit
-
-
Davi Arnaut authored
locking type of temp table The problem is that INSERT INTO .. SELECT FROM .. and CREATE TABLE .. SELECT FROM a temporary table could inadvertently overwrite the locking type of the temporary table. The lock type of temporary tables should be a write lock by default. The solution is to reset the lock type of temporary tables back to its default value after they are used in a statement.
-
- 29 Nov, 2008 1 commit
-
-
Georgi Kodinov authored
column When the storage engine uses secondary keys clustered with the primary key MySQL was adding the primary key parts to each secondary key. In doing so it was not checking whether the index was on full columns and this resulted in the secondary keys being added to the list of covering keys even if they have partial columns. Fixed by not adding a primary key part to the list of columns that can be used for index read of the secondary keys when the primary key part is a partial key part.
-
- 27 Nov, 2008 1 commit
-
-
Sergey Glukhov authored
The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win, If MySQL is compiled with valgrind there are errors about using of uninitialized variable(orig_table). The fix is to set field->orig_table correct value.
-
- 03 Nov, 2008 2 commits
-
-
Mats Kindahl authored
Adding missing drop of created table and tidying display.
-
Mats Kindahl authored
When statement-based replication is used, and the transaction isolation level is READ-COMMITTED or stricter, InnoDB will print an error because statement-based replication might lead to inconsistency between master and slave databases. However, when the binary log is not engaged, this is not an issue and an error should not be printed. This patch makes thd_binlog_format() return BINLOG_FORMAT_ UNSPEC when the binary log is not engaged for the given thread.
-
- 23 Jul, 2008 1 commit
-
-
Georgi Kodinov authored
Range scan in descending order for c <= <col> <= c type of ranges was ignoring the DESC flag. However some engines like InnoDB have the primary key parts as a suffix for every secondary key. When such primary key suffix is used for ordering ignoring the DESC is not valid. But we generally would like to do this because it's faster. Fixed by performing only reverse scan if the primary key is used. Removed some dead code in the process.
-
- 16 Jul, 2008 1 commit
-
-
Georgi Kodinov authored
Range scan in descending order for c <= <col> <= c type of ranges was ignoring the DESC flag. However some engines like InnoDB have the primary key parts as a suffix for every secondary key. When such primary key suffix is used for ordering ignoring the DESC is not valid. But we generally would like to do this because it's faster. Fixed by performing only reverse scan if the primary key is used. Removed some dead code in the process.
-
- 07 May, 2008 1 commit
-
-
sergefp@mysql.com authored
- Disable the "prefer full scan on clustered primary key over full scan of any secondary key" rule introduced by BUG#35850. - Update test results accordingly (bk trigger: file this for BUG#35850)
-
- 07 Feb, 2008 1 commit
-
-
gshchepa/uchum@host.loc authored
Minor post-fix for bug#34223.
-
- 08 Dec, 2007 1 commit
-
-
igor@olga.mysql.com authored
The index (key_part_1, key_part-2) was erroneously considered as compatible with the required ordering in the function test_test_if_order_by_key when a query with an ORDER BY clause contained a condition of the form key_part_1=const OR key_part_1 IS NULL and the order list contained only key_part_2. This happened because the value of the const_key_parts field in the KEYUSE structure was not formed correctly for the keys that could be used for ref_or_null access. This was fixed in the code of the update_ref_and_keys function. The problem could not manifest itself for MyISAM databases because the implementation of the keys_to_use_for_scanning() handler function always returns an empty bitmap for the MyISAM engine.
-
- 26 Oct, 2007 1 commit
-
-
file .\ha_innodb. Problem: if a partial unique key followed by a non-partial one we declare the second one as a primary key. Fix: sort non-partial unique keys before partial ones.
-
- 08 Oct, 2007 1 commit
-
-
serg@janus.mylan authored
fixed uninit memory access in SET pluginvar=DEFAULT innodb_mysql.test, innodb_mysql.result: test case for SET pluginvar=DEFAULT
-
- 04 Oct, 2007 1 commit
-
-
kaa@polly.(none) authored
Bug#28878: InnoDB tables with UTF8 character set and indexes cause wrong result for DML When making key reference buffers over CHAR fields whitespace (0x20) must be used to fill in the remaining space in the field's buffer. This is what Field_string::store() does. Fixed Field_string::get_key_image() to do the same.
-
- 14 Sep, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The optimizer sets index traversal in reverse order only if there are used key parts that are not compared to a constant. However using the primary key as an ORDER BY suffix rendered the check incomplete : going in reverse order must still be used even if all the parts of the secondary key are compared to a constant. Fixed by relaxing the check and set reverse traversal even when all the secondary index keyparts are compared to a const. Also account for the case when all the primary keys are compared to a constant.
-
- 27 Aug, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
The optimization that uses a unique index to remove GROUP BY, did not ensure that the index was actually used, thus violating the ORDER BY that is impled by GROUP BY. Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is simply removed.
-
- 15 Aug, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
ORDER BY is used The range analysis module did not correctly signal to the handler that a range represents a ref (EQ_RANGE flag). This causes non-range queries like SELECT ... FROM ... WHERE keypart_1=const, ..., keypart_n=const ORDER BY ... FOR UPDATE to wait for a lock unneccesarily if another running transaction uses SELECT ... FOR UPDATE on the same table. Fixed by setting EQ_RANGE for all range accesses that represent an equality predicate.
-
- 27 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
between perm and temp tables. Review fixes. The original bug report complains that if we locked a temporary table with LOCK TABLES statement, we would not leave LOCK TABLES mode when this temporary table is dropped. Additionally, the bug was escalated when it was discovered than when a temporary transactional table that was previously locked with LOCK TABLES statement was dropped, futher actions with this table, such as UNLOCK TABLES, would lead to a crash. The problem originates from incomplete support of transactional temporary tables. When we added calls to handler::store_lock()/handler::external_lock() to operations that work with such tables, we only covered the normal server code flow and did not cover LOCK TABLES mode. In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without matching ::external_lock(UNLOCK), e.g. when a transactional temporary table was dropped. Additionally, this table would be left in the list of LOCKed TABLES. The patch aims to address this inadequacy. Now, whenever an instance of 'handler' is destroyed, we assert that it was priorly external_lock(UNLOCK)-ed. All the places that violate this assert were fixed. This patch introduces no changes in behavior -- the discrepancy in behavior will be fixed when we start calling ::store_lock()/::external_lock() for all tables, regardless whether they are transactional or not, temporary or not.
-
- 20 Jul, 2007 2 commits
-
-
gkodinov/kgeorge@magare.gmz authored
ORDER BY primary_key on InnoDB table Queries that use an InnoDB secondary index to retrieve data don't need to sort in case of ORDER BY primary key if the secondary index is compared to constant(s). They can also skip sorting if ORDER BY contains both the the secondary key parts and the primary key parts (in that order). This is because InnoDB returns the rows in order of the primary key for rows with the same values of the secondary key columns. Fixed by preventing temp table sort for the qualifying queries.
-
gkodinov/kgeorge@magare.gmz authored
by long running transaction On Windows opened files can't be deleted. There was a special upgraded lock mode (TL_WRITE instead of TL_WRITE_ALLOW_READ) in ALTER TABLE to make sure nobody has the table opened when deleting the old table in ALTER TABLE. This special mode was causing ALTER TABLE to hang waiting on a lock inside InnoDB. This special lock is no longer necessary as the server is closing the tables it needs to delete in ALTER TABLE. Fixed by removing the special lock. Note that this also reverses the fix for bug 17264 that deals with another consequence of this special lock mode being used.
-
- 18 Jul, 2007 1 commit
-
-
Problem: we may break a multibyte char sequence using a key reduced to maximum allowed length for a storage engine (that leads to failed assertion in the innodb code, see also #17530). Fix: align truncated key length to multibyte char boundary.
-
- 15 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
Linux Debug build (possible deadlock)" The bug is not repeatable any more.
-
- 02 Jul, 2007 1 commit
-
-
sergefp@mysql.com authored
-