Commit graph

52 commits

Author SHA1 Message Date
unknown
c29002a5b6 Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/autopush/B29644-5.0-opt


sql/ha_innodb.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  5.0-opt merge
mysql-test/t/innodb_mysql.test:
  5.0-opt merge
2007-07-23 17:07:29 +03:00
unknown
240bb90ef1 Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/autopush/B28951-5.0-opt


mysql-test/t/innodb_mysql.test:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/table.cc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  merge of 5.0-opt
2007-07-22 19:23:29 +03:00
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
2007-07-20 21:05:29 +03:00
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.
2007-07-20 14:17:15 +03:00
unknown
b94fb82847 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.(none):/opt/local/work/mysql-5.0-runtime


mysql-test/t/sp.test:
  Auto merged
sql/item.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_show.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
mysql-test/r/innodb_mysql.result:
  Manual merge.
mysql-test/t/innodb_mysql.test:
  Manual merge.
2007-07-16 23:41:28 +04:00
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)"
2007-07-15 13:34:35 +04:00
unknown
16fc3a2771 Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt


mysql-test/r/innodb_mysql.result:
  Auto merged
mysql-test/t/innodb_mysql.test:
  Merge with 5.0 (main).
2007-07-08 00:19:31 +05:00
unknown
0b24005753 Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.0
into  labbari.dsl.inet.fi:/home/my/bk/mysql-5.0-marvel


libmysql/libmysql.c:
  Auto merged
mysql-test/r/innodb_mysql.result:
  Manual merge from main 5.1 to 5.1-marvel.
mysql-test/t/innodb_mysql.test:
  Manual merge from main 5.1 to 5.1-marvel.
2007-07-06 09:51:02 +03:00
unknown
b0696f5457 Fix testcase to be platform-independent 2007-07-02 22:18:41 +04:00
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.
2007-07-01 15:33:28 -07:00
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.
2007-06-25 10:44:52 +03:00
unknown
cb3ce981c7 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  mysql.com:/home/my/mysql-5.0


mysql-test/r/innodb_mysql.result:
  SCCS merged
mysql-test/t/innodb_mysql.test:
  SCCS merged
2007-06-20 19:25:44 +03:00
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)
2007-06-20 19:22:27 +03:00
unknown
6f168d1255 Merge bk@192.168.21.1:mysql-5.0
into  mysql.com:/d2/hf/mrg/mysql-5.0-opt


client/mysqltest.c:
  Auto merged
sql/field.cc:
  Auto merged
sql/field.h:
  Auto merged
sql/item.cc:
  Auto merged
sql/item.h:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/mysqld.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
mysql-test/r/innodb_mysql.result:
  merging
mysql-test/t/innodb_mysql.test:
  merging
sql/sql_select.cc:
  merging
2007-06-14 16:41:10 +05:00
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.
2007-06-07 10:08:44 +03:00
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.
2007-06-01 22:53:50 +05:00
unknown
dfc85a63b1 Merge olga.mysql.com:/home/igor/dev-opt/mysql-4.1-opt-bug28272
into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28272


mysql-test/r/innodb_mysql.result:
  Auto merged
mysql-test/t/innodb_mysql.test:
  Auto merged
sql/sql_select.cc:
  Manual merge
2007-05-15 13:16:10 -07:00
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.
2007-05-14 23:55:18 -07:00
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.
2007-05-10 00:06:24 -07:00
unknown
d812bcb955 Merge bk@192.168.21.1:mysql-5.0
into  mysql.com:/d2/hf/mrg/mysql-5.0-opt


CMakeLists.txt:
  Auto merged
sql/ha_innodb.cc:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
tests/mysql_client_test.c:
  Auto merged
mysql-test/r/innodb_mysql.result:
  merging
mysql-test/t/innodb_mysql.test:
  merging
2007-04-29 18:42:50 +05:00
unknown
edfa3dcf71 Merge gshchepa.loc:/home/uchum/work/bk-trees/mysql-4.1-opt
into  gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt-13191


mysql-test/r/innodb_mysql.result:
  SCCS merged
mysql-test/t/innodb_mysql.test:
  SCCS merged
sql/field.cc:
  Merge with 4.1, fix of bug #13191.
sql/field.h:
  Merge with 4.1, fix of bug #13191.
sql/key.cc:
  Merge with 4.1, fix of bug #13191.
2007-04-29 08:51:51 +05:00
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.
2007-04-29 04:16:17 +05:00
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.
2007-04-26 02:01:23 +05:00
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
2007-04-20 00:20:57 +02:00
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
2007-04-19 22:38:12 +02:00
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.
2007-02-10 23:55:56 -08:00
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.
2006-12-19 16:57:51 -07:00
unknown
f0364b7b84 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint


mysql-test/r/innodb_mysql.result:
  Auto merged
mysql-test/r/view.result:
  Auto merged
mysql-test/t/ctype_utf8.test:
  Auto merged
mysql-test/t/im_daemon_life_cycle.imtest:
  Auto merged
mysql-test/t/innodb_mysql.test:
  Auto merged
mysql-test/t/sp-error.test:
  Auto merged
mysql-test/t/sp.test:
  Auto merged
mysql-test/t/view.test:
  Auto merged
sql/ha_innodb.cc:
  Auto merged
sql/handler.cc:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/mysqld.cc:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sp.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_delete.cc:
  Auto merged
sql/sql_lex.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_trigger.cc:
  Auto merged
sql/sql_union.cc:
  Auto merged
sql/sql_view.cc:
  Auto merged
sql/sql_yacc.yy:
  Auto merged
sql/table.cc:
  Auto merged
tests/mysql_client_test.c:
  Auto merged
mysql-test/mysql-test-run.pl:
  Manual merge.
mysql-test/r/ps.result:
  Manual merge.
mysql-test/t/ps.test:
  Manual merge.
2006-11-02 17:39:52 -05:00
unknown
e1a722b2d3 Merge bk-internal.mysql.com:/home/bk/mysql-4.1
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint


configure.in:
  Auto merged
mysql-test/t/ps.test:
  Auto merged
sql/handler.cc:
  Auto merged
sql/sql_delete.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/table.cc:
  Auto merged
tests/mysql_client_test.c:
  Auto merged
myisam/sort.c:
  Manual merge.
mysql-test/r/innodb_mysql.result:
  Manual merge.
mysql-test/t/innodb_mysql.test:
  Manual merge.
mysys/mf_iocache.c:
  Manual merge.
2006-11-02 17:27:42 -05:00
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
2006-10-30 13:35:57 +01:00
unknown
853fb1ebfe Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819


mysql-test/r/innodb_mysql.result:
  Auto merged
mysql-test/t/innodb_mysql.test:
  Auto merged
sql/sql_delete.cc:
  Auto merged
2006-10-25 20:16:39 +04:00
unknown
6137ef86a9 Fix after manual merge. 2006-10-25 20:09:31 +04:00
unknown
e171a36efb Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug18819
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819


mysql-test/r/innodb_mysql.result:
  Manual merge.
mysql-test/t/innodb_mysql.test:
  Manual merge.
sql/sql_delete.cc:
  Manual merge.
2006-10-25 20:00:51 +04:00
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).
2006-10-25 19:53:26 +04:00
unknown
d4bfae38ac Merge siva.hindu.god:/usr/home/tim/m/bk/g50
into  siva.hindu.god:/usr/home/tim/m/bk/50


configure.in:
  Auto merged
mysql-test/r/rename.result:
  Auto merged
mysql-test/r/subselect.result:
  Auto merged
mysql-test/r/view.result:
  Auto merged
mysql-test/t/subselect.test:
  Auto merged
mysql-test/t/view.test:
  Auto merged
mysys/mf_iocache.c:
  Auto merged
sql/item_func.cc:
  Auto merged
sql/opt_range.cc:
  Auto merged
sql/opt_range.h:
  Auto merged
sql/sql_lex.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/table.cc:
  Auto merged
myisam/sort.c:
  Manual merge
mysql-test/r/innodb_mysql.result:
  Manual merge
mysql-test/t/innodb_mysql.test:
  Manual merge
2006-10-24 14:42:08 -06:00
unknown
15a86d185d Merge neptunus.(none):/home/msvensson/mysql/bug22436/my50-bug22436
into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint


mysql-test/r/innodb_mysql.result:
  Auto merged
mysql-test/t/innodb_mysql.test:
  Auto merged
mysql-test/t/sp.test:
  Auto merged
mysql-test/r/create.result:
  Merge
mysql-test/t/create.test:
  Merge
mysql-test/t/view.test:
  Remove the disable_warnings part as engine=innodb has been removed
2006-10-19 01:01:54 +02:00
unknown
b2bf4843c7 Merge shellback.(none):/home/msvensson/mysql/mysql-4.1-maint
into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint


client/mysql.cc:
  Auto merged
client/mysqldump.c:
  Auto merged
client/mysqltest.c:
  Auto merged
include/my_dbug.h:
  Auto merged
mysql-test/lib/mtr_cases.pl:
  Auto merged
mysql-test/lib/mtr_report.pl:
  Auto merged
mysql-test/mysql-test-run.pl:
  Auto merged
mysql-test/r/csv.result:
  Auto merged
mysql-test/r/func_time.result:
  Auto merged
mysql-test/t/csv.test:
  Auto merged
sql/field.cc:
  Auto merged
sql/handler.cc:
  Auto merged
sql/item_timefunc.cc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  Manual merge
mysql-test/t/func_time.test:
  Manual merge, test already there
mysql-test/t/innodb_mysql.test:
  Manual merge
2006-10-14 19:55:06 +02:00
unknown
72a997c0ea Merge polly.local:/tmp/maint/bug22728/my41-bug22728
into  polly.local:/home/kaa/src/maint/m41-maint--07OGk


sql/handler.cc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  Manually merged
mysql-test/t/innodb_mysql.test:
  Manually merged
2006-10-12 13:39:52 +04:00
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.
2006-10-11 12:44:03 +04:00
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.
2006-10-09 19:51:41 +04:00
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.
2006-09-28 15:13:40 +02:00
unknown
3a8cdfc3ed Merge bug #16792 4.1->5.0 2006-09-05 19:07:55 +03:00
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
2006-08-21 14:20:03 +04:00
unknown
4ed157ee86 BUG#21077: 4.1->5.0 merge 2006-08-15 21:16:02 +04:00
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
2006-08-15 20:33:14 +04:00
unknown
4f580b3e43 Merge macbook.gmz:/Users/kgeorge/mysql/work/B17212-4.1-opt
into  macbook.gmz:/Users/kgeorge/mysql/work/B17212-5.0-opt


mysql-test/r/innodb_mysql.result:
  Merge 4.1->5.0 for bug #17212
mysql-test/t/innodb_mysql.test:
  Merge 4.1->5.0 for bug #17212
sql/sql_select.cc:
  Merge 4.1->5.0 for bug #17212
2006-07-14 11:20:52 +03:00
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
2006-07-12 10:57:38 +03:00
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
2006-05-23 16:43:01 +03:00
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
2006-05-22 16:10:53 +03:00
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.
2006-05-06 13:15:00 +04:00