mariadb

Commit Graph

Author	SHA1	Message	Date
Sergey Glukhov	1182c0979a	Bug#37284 Crash in Field_string::type() 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. mysql-test/r/innodb_mysql.result: test result mysql-test/t/innodb_mysql.test: test case sql/sql_base.cc: set field->orig_table to 'table' value because it may be bogus and it leads to crash on Field_string::type() function.	17 years ago
Georgi Kodinov	dd85aa78ba	Bug#37830 : ORDER BY ASC/DESC - no difference 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. mysql-test/r/innodb_mysql.result: Bug#37830 : test case mysql-test/t/innodb_mysql.test: Bug#37830 : test case sql/opt_range.cc: Bug#37830 : - preserve and use used_key_parts to distinguish when a primary key suffix is used - removed some dead code sql/opt_range.h: Bug#37830 : - preserve used_key_parts - dead code removed sql/sql_select.cc: Bug#37830 : Do only reverse order traversal if the primary key suffix is used.	18 years ago
unknown	a4eaf17ccb	innodb_mysql.test, variables.result, variables.test, innodb_mysql.result: Minor post-fix for bug#34223. mysql-test/r/innodb_mysql.result: Minor post-fix for bug#34223. mysql-test/r/variables.result: Minor post-fix for bug#34223. mysql-test/t/innodb_mysql.test: Minor post-fix for bug#34223. mysql-test/t/variables.test: Minor post-fix for bug#34223.	18 years ago
unknown	d776054e00	Fixed bug #32815 . 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. mysql-test/r/innodb_mysql.result: Added a test case for bug #32815. mysql-test/t/innodb_mysql.test: Added a test case for bug #32815. sql/sql_select.cc: Fixed bug #32815. 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.	18 years ago
unknown	d7d93cf548	Fix for bug #31137 : Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, 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. include/my_base.h: Fix for bug #31137: Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, file .\ha_innodb. - sort unique keys that don't contain partial segments before other keys: set HA_KEY_HAS_PART_KEY_SEG flag for such keys in the mysql_prepare_table(), use it in the sort_keys(); mysql-test/r/innodb_mysql.result: Fix for bug #31137: Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, file .\ha_innodb. - test result. mysql-test/r/key.result: Fix for bug #31137: Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, file .\ha_innodb. - test result. mysql-test/t/innodb_mysql.test: Fix for bug #31137: Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, file .\ha_innodb. - test case. mysql-test/t/key.test: Fix for bug #31137: Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, file .\ha_innodb. - test case. sql/sql_table.cc: Fix for bug #31137: Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, file .\ha_innodb. - sort unique keys that don't contain partial segments before other keys: set HA_KEY_HAS_PART_KEY_SEG flag for such keys in the mysql_prepare_table(), use it in the sort_keys(); sql/structs.h: Fix for bug #31137: Assertion failed: primary_key_no == -1 \|\| primary_key_no == 0, file .\ha_innodb. - sort unique keys that don't contain partial segments before other keys: set HA_KEY_HAS_PART_KEY_SEG flag for such keys in the mysql_prepare_table(), use it in the sort_keys();	18 years ago
unknown	4d0ef0cc85	Backport of the 5.0 patch to 4.1 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. mysql-test/r/innodb_mysql.result: Bug#28878: test case mysql-test/t/innodb_mysql.test: Bug#28878: test case sql/field.cc: Bug#28878: Fill with space instead of binary zeros.	18 years ago
unknown	ad496be063	Bug #31001 : ORDER BY DESC in InnoDB not working 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. mysql-test/r/innodb_mysql.result: Bug #31001: test case mysql-test/t/innodb_mysql.test: Bug #31001: test case sql/sql_select.cc: Bug #31001: - account for the case when all the primary key parts are compared to a constant - force test_if_skip_sort_order to go backwards over the key even when the number of keyparts used is the same as the number of keyparts equal to a constant. (because of the primary key suffix).	19 years ago
unknown	2368664681	Bug #30596 GROUP BY optimization gives wrong result order 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. BitKeeper/etc/ignore: Added support-files/mysqld_multi.server tests/bug25714 cscope.in.out cscope.out cscope.po.out to the ignore list mysql-test/r/distinct.result: Bug#30596: Changed test case. Prior to Bug#16458, These queries use temp table and filesort. The bug was that they used a temp table. However, that patch removed filesort also, in which case we can no longer gurantee correct ordering. mysql-test/r/group_by.result: Bug#30596: Correct result mysql-test/r/innodb_mysql.result: Bug#30596: Test case for innodb. Here, as opposed to for MyISAM, row lookup is done using index whenever the index covers the group list. mysql-test/t/group_by.test: Bug#30596: Test case mysql-test/t/innodb_mysql.test: Bug#30596: Test case sql/sql_select.cc: Bug#30596: The fix, replacing GROUP BY with ORDER BY unless ORDER BY [NULL\|<constant>]	19 years ago
unknown	01f8130aa6	bug#28570: handler::index_read() is called with different find_flag when 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. mysql-test/r/innodb_mysql.result: bug#28570: Test Result mysql-test/t/innodb_mysql.test: bug#28570: Test Case sql/handler.cc: bug#28570: Updated comment sql/opt_range.cc: bug#28570: Removed the criterion that key has to be unique (HA_NOSAME) in order for the EQ_RANGE flag to be set. It is sufficient that the range represent a ref access.	19 years ago
unknown	0936976e8d	A fix and a test case for Bug#24918 drop table and lock / inconsistent 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. mysql-test/r/innodb_mysql.result: Update test results (Bug#24918) mysql-test/t/innodb_mysql.test: Add a test case for Bug#24918 sql/handler.h: Make handler::external_lock() a protected method. Backport from 5.1 its public wrapper handler::ha_external_lock(). Assert that the handler is not closed if it is still locked. sql/lock.cc: In mysql_lock_tables only call lock_external() for the list of tables that we called store_lock() for. E.g. get_lock_data() does not add non-transactional temporary tables to the lock list, so lock_external() should not be called for them. Use handler::ha_external_lock() instead of handler::external_lock(). Add comments for mysql_lock_remove(), parameterize one strange side effect that it has. At least in one place where mysql_lock_remove is used, this side effect is not desired (DROP TABLE). The parameter will be dropped in 5.1, along with the side effect. sql/mysql_priv.h: Update declaration of mysql_lock_remove(). sql/opt_range.cc: Deploy handler::ha_external_lock() instead of handler::external_lock() sql/sql_base.cc: When closing a temporary table, remove the table from the list of LOCKed TABLES of this thread, in case it's there. It's there if it is a transactional temporary table. Use a new declaration of mysql_lock_remove(). sql/sql_class.h: Extend the comment for THD::temporary_tables. sql/sql_table.cc: Deploy handler::ha_external_lock() instead of handler::external_lock()	19 years ago
unknown	95a8c6c327	Bug #28591 : MySQL need not sort the records in case of 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. mysql-test/r/innodb_mysql.result: Bug #28591: test case mysql-test/t/innodb_mysql.test: Bug #28591: test case sql/sql_select.cc: Bug #28591: Use the primary key as suffix when testing if the key can be used for ORDER BY on supporting engines. sql/table.cc: Bug #28591: can use the primary key as a suffix for the secondary keys	19 years ago
unknown	eea5c2a3c5	Bug #29644 : alter table hangs if records locked in share mode 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. mysql-test/r/innodb_mysql.result: Bug #29644: test case mysql-test/t/innodb_mysql.test: Bug #29644: test case sql/ha_innodb.cc: Bug #29644: reverse the (now excessive) fix for bug 17264 (but leave the test case). sql/sql_base.cc: Bug #29644: don't need a special lock mode for Win32 anymore: the table is closed before the drop.	19 years ago
unknown	6947f2d131	Fix for bug #28125 : ERROR 2013 when adding index. 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. mysql-test/r/innodb_mysql.result: Fix for bug #28125: ERROR 2013 when adding index. - test result. mysql-test/t/innodb_mysql.test: Fix for bug #28125: ERROR 2013 when adding index. - test case. sql/sql_table.cc: Fix for bug #28125: ERROR 2013 when adding index. - align truncated key length to multibyte char boundary. - display real key length in bytes raising warnings.	19 years ago
unknown	8023d91929	Add a teste case for Bug#27296 "Assertion in ALTER TABLE SET DEFAULT in Linux Debug build (possible deadlock)" The bug is not repeatable any more. mysql-test/r/innodb_mysql.result: Update test results (Bug#27296) mysql-test/t/innodb_mysql.test: Add a teste case for Bug#27296 "Assertion in ALTER TABLE SET DEFAULT in Linux Debug build (possible deadlock)"	19 years ago
unknown	b0696f5457	Fix testcase to be platform-independent	19 years ago
unknown	07dcc80023	Fixed bug #25798 . 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. mysql-test/r/innodb_mysql.result: Added a test case for bug #25798. mysql-test/t/innodb_mysql.test: Added a test case for bug #25798. sql/filesort.cc: Fixed bug #25798. The function merge_buffers() when called from the Uniques::get method must use function buffpek_compare to compare elements in the queue it employs. The pointer to buffpek_compare and the info for the function that compares sorted records are passed to merge_buffers through certain designated fields of the SORTPARAM structure. sql/sql_sort.h: Fixed bug #25798. Added fields to the SORTPARAM structure to be used in the function merge_buffers when called by the Uniques::get method. sql/uniques.cc: Fixed bug 25798. The function merge_buffers() when called from the Uniques::get method must use function buffpek_compare to compare elements in the queue it employes.	19 years ago
unknown	39459397cd	Bug #29154 : LOCK TABLES is not atomic when >1 InnoDB tables are locked 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. mysql-test/r/innodb_mysql.result: Bug #29154: test case mysql-test/t/innodb_mysql.test: Bug #29154: test case sql/sql_parse.cc: Bug #29154: end the trasaction at a failing LOCK TABLES so the handler can free its locks.	19 years ago
unknown	9b8b0000ce	Allow multiple calls to mysql_server_end() (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) BitKeeper/etc/ignore: added include/abi_check libmysql/libmysql.c: Allow multiple calls to mysql_server_end() (Part of fix for Bug#25621 Error in my_thread_global_end(): 1 threads didn't exit) mysql-test/r/innodb_mysql.result: Test case for drop of table that only has a .frm file mysql-test/t/innodb_mysql.test: Test case for drop of table that only has a .frm file sql/ha_innodb.cc: 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)	19 years ago
unknown	970b26e679	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. mysql-test/r/innodb_mysql.result: Bug#28878: test case mysql-test/t/innodb_mysql.test: Bug#28878: test case sql/field.cc: Bug#28878: Fill with space instead of binary zeros.	19 years ago
unknown	55aa43e2f5	Fix for bug #28652 : MySQL (with-debug=full) asserts when alter table operations 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. mysql-test/r/innodb_mysql.result: Fix for bug #28652: MySQL (with-debug=full) asserts when alter table operations - test result. mysql-test/t/innodb_mysql.test: Fix for bug #28652: MySQL (with-debug=full) asserts when alter table operations - test case. sql/sql_table.cc: Fix for bug #28652: MySQL (with-debug=full) asserts when alter table operations - commit moved to happen earlier in the mysql_alter_table(), now we commit changes at the same time as in case when a temporary table is used.	19 years ago
unknown	8762539d47	Fixed bug #28272 : crash that occurs when running an EXPLAIN command 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. mysql-test/r/innodb_mysql.result: Added a test case for bug #28272. mysql-test/t/innodb_mysql.test: Added a test case for bug #28272. sql/sql_select.cc: Fixed bug #28272: crash that occurs when running an EXPLAIN command 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. Such attempts could be observed only with EXPLAIN commands. Now at the optimization phase the WHERE condition is never evaluated if there is no record previously read from the table.	19 years ago
unknown	184cc3b5fa	Fixed bug #28189 : in some rare cases optimizer preferred a more expensive ref access to a less expensive range access. This occurred only with InnoDB tables. mysql-test/r/innodb_mysql.result: Added a test case for bug #28189. mysql-test/t/innodb_mysql.test: Added a test case for bug #28189.	19 years ago
unknown	98c0da4ed5	Fixed bug #13191 . 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. mysql-test/t/innodb_mysql.test: Added test case for bug #13191. mysql-test/r/innodb_mysql.result: Added test case for bug #13191. sql/field.h: Fixed bug #13191. Field_string::get_key_image() virtual function was overloaded to implement copying of variable length character (UTF-8) fields. Field::get_key_image() function prototype has been changed to return byte size of copied data. sql/field.cc: Fixed bug #13191. Field_string::get_key_image() virtual function was overloaded to implement copying of variable length character (UTF-8) fields. Field::get_key_image() function prototype has been changed to return byte size of copied data. sql/key.cc: Fixed bug #13191. INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: "Can't find record in ...". This error occurs because INSERT...ON DUPLICATE uses a wrong procedure to copy field parts for index search. key_copy() function has been fixed.	19 years ago
unknown	209bf25a7f	Fixed bug #27650 : 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. sql/ha_innodb.cc: Fixed bug #27650. 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. ha_innobase::write_row() function has been corrected. mysql-test/t/innodb_mysql.test: Added a test case for bug #27650. mysql-test/r/innodb_mysql.result: Added a test case for bug #27650.	19 years ago
unknown	5222d83f9d	innodb_mysql.test, innodb_mysql.result: Fix test case: add drop table mysql-test/t/innodb_mysql.test: Fix test case: add drop table mysql-test/r/innodb_mysql.result: Fix test case: add drop table	19 years ago
unknown	f4d6b5de91	innodb_mysql.test, innodb_mysql.result: Add test case for Bug #27210: INNODB ON DUPLICATE KEY UPDATE mysql-test/r/innodb_mysql.result: Add test case for Bug #27210: INNODB ON DUPLICATE KEY UPDATE mysql-test/t/innodb_mysql.test: Add test case for Bug #27210: INNODB ON DUPLICATE KEY UPDATE	19 years ago
unknown	3e4f834dfb	Fixed bug #26159 . 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. mysql-test/r/innodb_mysql.result: Added a test case for bug #26159. mysql-test/t/innodb_mysql.test: Added a test case for bug #26159. sql/opt_range.cc: Fixed bug #26159. 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. For an empty table quick_prefix_select->reset() was not called at all and thus some important initialization steps were missing.	19 years ago
unknown	47b0a0b089	Added innodb_rollback_on_timeout option to restore the 4.1 InnoDB timeout behavior (Bug #24200) mysql-test/t/innodb_mysql-master.opt: Set --innodb-lock-wait-timeout=2, since test for bug #24200 times out. This could cause random test failures if some long-running transaction concurrency is being tested. However, such a test really should go in innodb-big or some other test file.	19 years ago
unknown	e948c64ff5	Improve comments around FLUSH STATUS 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 mysql-test/r/innodb_mysql.result: Update result file mysql-test/t/innodb_mysql.test: It's not possible to reset the global status variables in 5.0 so intead its value is recorded and compared to the after value. It should not have changed. sql/mysqld.cc: Improve comments sql/set_var.cc: Improve comments sql/sql_class.cc: Improve comments sql/sql_class.h: Improve comments	19 years ago
unknown	e3d49f0c3f	BUG#18819: DELETE IGNORE hangs on foreign key parent delete 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. mysql-test/r/innodb_mysql.result: Add result for bug#18819: DELETE IGNORE hangs on foreign key parent delete. mysql-test/t/innodb_mysql.test: Add test case for bug#18819: DELETE IGNORE hangs on foreign key parent delete. sql/sql_delete.cc: Report success if we have got an error, but we are in DELETE IGNORE, and the error is not fatal (if it is, it would be reported to the client).	19 years ago
unknown	ca126a2bbd	Fix for bug #22728 "Handler_rollback value is growing". 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. mysql-test/r/innodb_mysql.result: Added testcase for bug #22728 "Handler_rollback value is growing" mysql-test/t/innodb_mysql.test: Added testcase for bug #22728 "Handler_rollback value is growing" sql/handler.cc: 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.	19 years ago
unknown	45cad70ff4	Bug #22781 : SQL_BIG_RESULT fails to influence sort plan 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. mysql-test/r/bdb.result: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - updated sql_big_result testcase mysql-test/r/group_by.result: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - test case with MyISAM mysql-test/r/innodb.result: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - updated sql_big_result testcase mysql-test/r/innodb_mysql.result: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - test case with InnoDB mysql-test/r/myisam.result: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - updated sql_big_result testcase mysql-test/t/group_by.test: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - test case with MyISAM mysql-test/t/innodb_mysql.test: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - test case with InnoDB sql/sql_select.cc: Bug #22781: SQL_BIG_RESULT fails to influence sort plan - When SQL_BIG_RESULT is specified, disable the optimization performed at execution/explain time that decides to use an index instead of filesort.	19 years ago
unknown	d8d57c77b1	Bug#22436 Four tests require "innodb" to be configured, fail in "classic" build - Disable warnings when creating the "innodb" tables if it works anyway. - Move test that are really innodb dependent to innodb_mysql mysql-test/r/create.result: Move the innodb dependent test to innodb_mysql.test mysql-test/r/innodb_mysql.result: Move the innodb dependent test to innodb_mysql.test mysql-test/t/create.test: Move the innodb dependent test to innodb_mysql.test mysql-test/t/innodb_mysql.test: Move the innodb dependent test to innodb_mysql.test mysql-test/t/lock_multi.test: Disable warnings while creating the innodb table. If innodb is not available, the table will be created with default engine and thus create a warning. Regardless of this, test output should be the same. mysql-test/t/sp.test: Disable warnings while creating the innodb table. If innodb is not available, the table will be created with default engine and thus create a warning. Regardless of this, test output should be the same. mysql-test/t/view.test: Disable warnings while creating the innodb table. If innodb is not available, the table will be created with default engine and thus create a warning. Regardless of this, test output should be the same.	20 years ago
unknown	d2fa8e3a8d	Fix by Georgi Kodinov: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/r/innodb_mysql.result: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/r/join_outer.result: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/t/innodb_mysql.test: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file mysql-test/t/join_outer.test: Bug #18744 Test 'join_outer' fails if "classic" configuration in 5.0 - moved an InnoDB dependent test to the appropriate file	20 years ago
unknown	9907e970ae	BUG#21077: Possible crash caused by invalid sequence of handler::* calls: The crash was caused by invalid sequence of handler::** calls: ha_smth->index_init(); ha_smth->index_next_same(); (2) (2) is an invalid call as it was not preceeded by any 'scan setup' call like index_first() or index_read(). The cause was that QUICK_SELECT::reset() didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten, and quick select might attempt to continue reading the range, which would result in the above mentioned invalid sequence of handler calls. 5.x versions are not affected by the bug - they already have the missing "range=NULL" clause. mysql-test/r/innodb_mysql.result: Testcase for BUG#21077 mysql-test/t/innodb_mysql.test: Testcase for BUG#21077 sql/opt_range.h: BUG#21077: Possible crash caused by invalid sequence of handler::* calls: - Make QUICK_SELECT::reset() really reset the quick select	20 years ago
unknown	4144543006	Bug #17212 results not sorted correctly by ORDER BY when using index * don't use join cache when the incoming data set is already ordered for ORDER BY This choice must be made because join cache will effectively reverse the join order and the results will be sorted by the index of the table that uses join cache. mysql-test/r/innodb_mysql.result: Bug #17212 results not sorted correctly by ORDER BY when using index * Test suite for the bug mysql-test/t/innodb_mysql.test: Bug #17212 results not sorted correctly by ORDER BY when using index * Test suite for the bug sql/sql_select.cc: Bug #17212 results not sorted correctly by ORDER BY when using index * don't use join cache when the incoming data set is already sorted	20 years ago
unknown	f112e407ea	Bug #18742 : Test 'group_min_max' fails if "classic" configuration in 5.0 Moved the InnoDB related tests to innodb_mysql mysql-test/r/group_min_max.result: Moved innodb related tests out of group_min_max mysql-test/r/innodb_mysql.result: Moved innodb related tests out of group_min_max mysql-test/t/group_min_max.test: Moved innodb related tests out of group_min_max mysql-test/t/innodb_mysql.test: Moved innodb related tests out of group_min_max	20 years ago
unknown	af3b08c585	Bug#18745: Test case 'func_group' fails if "classic" 5.0 configuration Moved the InnoDB related test from func_group.test to innodb_mysql.test mysql-test/r/func_group.result: Moved a test to innodb_mysql mysql-test/r/innodb_mysql.result: moved a test to innodb_mysql mysql-test/t/func_group.test: Moved a test to innodb_mysql mysql-test/t/innodb_mysql.test: Moved a test to innodb_mysql	20 years ago
unknown	c13144722a	BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known. The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a constant). TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields(). mysql-test/r/innodb_mysql.result: Testcase for BUG16798 mysql-test/t/innodb_mysql.test: Testcase for BUG16798 sql/sql_select.cc: BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions In merge_key_fields() don't call val->is_null() if the value of val is not known.	20 years ago
unknown	c2e6c898ac	Make innodb_mysql produce a non-empty output. mysql-test/r/innodb_mysql.result: Fix result.	20 years ago
unknown	a4c62dbb8a	Files innodb.[test\|result] are to be used by Innobase only. Use files innodb_mysql.[test\|result] instead. mysql-test/t/innodb.test: This file is to be used by Innobase only. mysql-test/r/innodb_mysql.result: New BitKeeper file ``mysql-test/r/innodb_mysql.result'' Use this file instead of innodb.result. mysql-test/t/innodb_mysql.test: New BitKeeper file ``mysql-test/t/innodb_mysql.test'' Use this file instead of innodb.test.	20 years ago

1 2

67 Commits (3b617acb87bce94b6ac27e3d91017cfaa9d67b83)