An error occurred fetching the project authors.
- 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
-
- 01 Jul, 2007 1 commit
-
-
igor@olga.mysql.com authored
This bug may manifest itself not only with the queries for which the index-merge access method is chosen. It also may display itself for queries with DISTINCT. The bug was in how the Unique::get method used the merge_buffers function. To compare elements in the the queue employed by merge_buffers() it must use the buffpek_compare function rather than the function for binary comparison.
-
- 25 Jun, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
LOCK TABLES takes a list of tables to lock. It may lock several tables successfully and then encounter a tables that it can't lock, e.g. because it's locked. In such case it needs to undo the locks on the already locked tables. And it does that. But it has also notified the relevant table storage engine handlers that they should lock. The only reliable way to ensure that the table handlers will give up their locks is to end the transaction. This is what UNLOCK TABLE does : it ends the transaction if there were locked tables by LOCK tables. It is possible to end the transaction when the lock fails in LOCK TABLES because LOCK TABLES ends the transaction at its start already. Fixed by ending (again) the transaction when LOCK TABLES fails to lock a table.
-
- 20 Jun, 2007 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
(Part of fix for Bug#25621 Error in my_thread_global_end(): 1 threads didn't exit) Give correct error message if InnoDB table is not found (This allows us to drop a an innodb table that is not in the InnoDB registery)
-
- 07 Jun, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
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.
-
- 01 Jun, 2007 1 commit
-
-
Problem: we may create a deadlock committing changes in the mysql_alter_table() when LOCK_open is set. Moreover, "in some variants of the ALTER TABLE commit happens earlier, outside of LOCK_open, in other later - inside. It's no good, a storage engine code that is called in between could expect a consistency - either there is a transaction or there is not". Fix: move the commit to happen earlier and outside of the LOCK_open.
-
- 15 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
for a query over an empty table right after its creation. The crash is the result of an attempt made by JOIN::optimize to evaluate the WHERE condition when no records have been actually read. The added test case can reproduce the crash only with InnoDB tables and only with 5.0.x.
-
- 10 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
ref access to a less expensive range access. This occurred only with InnoDB tables.
-
- 28 Apr, 2007 1 commit
-
-
gshchepa/uchum@gshchepa.loc authored
INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: "Can't find record in ..." if we are inserting into InnoDB table unique index of partial key with underlying UTF-8 string field. This error occurs because INSERT...ON DUPLICATE uses a wrong procedure to copy string fields of multi-byte character sets for index search.
-
- 25 Apr, 2007 1 commit
-
-
gshchepa/uchum@gshchepa.loc authored
INSERT into InnoDB table may cause "ERROR 1062 (23000): Duplicate entry..." errors or lost records after multi-row INSERT of the form: "INSERT INTO t (id...) VALUES (NULL...) ON DUPLICATE KEY UPDATE id=VALUES(id)", where "id" is an AUTO_INCREMENT column. It happens because InnoDB handler forgets to save next insert id after updating of auto_increment column with new values. As result of that last insert id stored inside InnoDB dictionary tables differs from it's cached thd->next_insert_id value.
-
- 19 Apr, 2007 2 commits
-
-
tsmith@quadxeon.mysql.com authored
Fix test case: add drop table
-
tsmith@quadxeon.mysql.com authored
Add test case for Bug #27210: INNODB ON DUPLICATE KEY UPDATE
-
- 11 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset caused a crash when a query with DISTINCT was executed by a loose scan for an InnoDB table that had been emptied.
-
- 19 Dec, 2006 1 commit
-
-
tsmith/tim@siva.hindu.god authored
InnoDB timeout behavior (Bug #24200)
-
- 30 Oct, 2006 1 commit
-
-
msvensson@shellback.(none) authored
It's not possible to flush the global status variables in 5.0 Update test case so it works by recording the value of handle_rollback before and compare it to the value after
-
- 25 Oct, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
If the error happens during DELETE IGNORE, nothing could be send to the client, thus leaving it frozen expecting the reply. The problem was that if some error occurred, it wouldn't be reported to the client because of IGNORE, but neither success would be reported. MySQL 4.1 would not freeze the client, but will report ERROR 1105 (HY000): Unknown error instead, which is also a bug. The solution is to report success if we are in DELETE IGNORE and some non-fatal error has happened.
-
- 11 Oct, 2006 1 commit
-
-
kaa@polly.local authored
The bug is present only in 4.1, will be null-merged to 5.0 For InnoDB, check value of thd->transaction.all.innodb_active_trans instead of thd->transaction.stmt.innobase_tid to see if we really need to rollback.
-
- 09 Oct, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.local authored
Currently SQL_BIG_RESULT is checked only at compile time. However, additional optimizations may take place after this check that change the sort method from 'filesort' to sorting via index. As a result the actual plan executed is not the one specified by the SQL_BIG_RESULT hint. Similarly, there is no such test when executing EXPLAIN, resulting in incorrect output. The patch corrects the problem by testing for SQL_BIG_RESULT both during the explain and execution phases.
-