An error occurred fetching the project authors.
- 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 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 4 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.
-
- 16 Jul, 2007 2 commits
-
-
kostja@bodhi.(none) authored
-
svoj@mysql.com/june.mysql.com authored
internal data dictionary - re-enabled innodb_mysql test; - added a rule to through away expected warning to mtr_report.pl; - fixed a test case to produce unique warning.
-
- 15 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
Linux Debug build (possible deadlock)" The bug is not repeatable any more.
-
- 08 Jul, 2007 1 commit
-
-
evgen@moonbone.local authored
When a table is being updated it has two set of fields - fields required for checks of conditions and fields to be updated. A storage engine is allowed not to retrieve columns marked for update. Due to this fact records can't be compared to see whether the data has been changed or not. This makes the server always update records independently of data change. Now when an auto-updatable timestamp field is present and server sees that a table handle isn't going to retrieve write-only fields then all of such fields are marked as to be read to force the handler to retrieve them.
-
- 04 Jul, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
-
- 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.
-
- 04 Jun, 2007 1 commit
-
-
- 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.
-
- 29 May, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
- Renamed "Using join cache" to "Using join buffer". - "Using join buffer" is now printed on the last table that "reads" from the join buffer cache.
-
- 19 May, 2007 1 commit
-
-
dlenev@mockturtle.local authored
and invalidation in the most general case (non-temporary table and not simple RENAME or ENABLE/DISABLE KEYS or partitioning command). See comment for sql/sql_table.cc for more information. These changes are prerequisite for 5.1 version of fix for bug #23667 "CREATE TABLE LIKE is not isolated from alteration by other connections"
-
- 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.
-
- 14 May, 2007 1 commit
-
-
dlenev@mockturtle.local authored
TABLES" and failures of alter_table.test on Windows which occured after pushing fix for bugs #20662, #20903, #24508, #24738 (various problems with CREATE TABLE SELECT). ALTER TABLE statements which were handled using "fast" alter table optimization were not properly working under LOCK TABLES if table was transactional (for all table types under Windows). Code implementing "fast" version of ALTER TABLE tried to open and lock table using open_ltable() after renaming .FRM files (which corresponds to renaming tables in normal case) in some cases (for transactional tables or on Windows). This caused problems under LOCK TABLES and conflicted with name-lock taken by ALTER TABLE RENAME on target tables. This patch solves this issue by using reopen_name_locked_table() instead of open_ltable().
-
- 10 May, 2007 1 commit
-
-
igor@olga.mysql.com authored
ref access to a less expensive range access. This occurred only with InnoDB tables.
-
- 04 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
- added join cache indication in EXPLAIN (Extra column). - prefer filesort over full scan over index for ORDER BY (because it's faster). - when switching from REF to RANGE because RANGE uses longer key turn off sort on the head table only as the resulting RANGE access is a candidate for join cache and we don't want to disable it by sorting on the first table only.
-
- 29 Apr, 2007 2 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
- 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 3 commits
-
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
-
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.
-
- 28 Sep, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
- Disable warnings when creating the "innodb" tables if it works anyway. - Move test that are really innodb dependent to innodb_mysql
-