into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt


mysql-test/r/ps.result:
  Auto merged
mysql-test/t/ps.test:
  Auto merged
sql/item.cc:
  Auto merged

into  sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0


mysql-test/r/ps.result:
  Auto merged
mysql-test/t/ps.test:
  Auto merged
sql/item.cc:
  Auto merged

mysql-test/r/sp_trans.result:
  added cleanup
mysql-test/r/strict.result:
  added cleanup
mysql-test/t/sp_trans.test:
  added cleanup
mysql-test/t/strict.test:
  added cleanup

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt


mysql-test/r/ps.result:
  Auto merged
mysql-test/t/ps.test:
  Auto merged
sql/item.cc:
  Auto merged

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb


ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
  Auto merged

into  moonbone.local:/mnt/gentoo64/work/28261-bug-5.0-opt-mysql

into  perch.ndb.mysql.com:/home/jonas/src/50-work


ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
  Auto merged

  review comment 2, atleast 1 signal need for test prg


ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
  review comment, atleast 1 signal need

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb


ndb/src/common/transporter/TransporterRegistry.cpp:
  Auto merged

into  perch.ndb.mysql.com:/home/jonas/src/50-work


ndb/src/common/transporter/TransporterRegistry.cpp:
  Auto merged

  review comment
  if some tcp-transporter has data, then do select with timeout 0


ndb/src/common/transporter/TransporterRegistry.cpp:
  review comment
  if some tcp-transporter has data, then do select with timeout 0

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb


ndb/src/common/transporter/Packer.cpp:
  Auto merged
ndb/src/common/transporter/TCP_Transporter.hpp:
  Auto merged
ndb/src/common/transporter/TransporterRegistry.cpp:
  Auto merged
ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
  Auto merged
ndb/test/ndbapi/testNdbApi.cpp:
  merge
ndb/test/run-test/daily-basic-tests.txt:
  merge

into  perch.ndb.mysql.com:/home/jonas/src/50-work


ndb/src/common/transporter/Packer.cpp:
  Auto merged
ndb/src/common/transporter/TCP_Transporter.hpp:
  Auto merged
ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
  Auto merged
ndb/src/common/transporter/TransporterRegistry.cpp:
  merge
ndb/test/ndbapi/testNdbApi.cpp:
  merge
ndb/test/run-test/daily-basic-tests.txt:
  merge

  Make sure that data can not e left lingering in receive buffer


ndb/src/common/transporter/Packer.cpp:
  test, make MAX_RECEIVED_SIGNALS an variable
ndb/src/common/transporter/TCP_Transporter.hpp:
  add new method for checking of data in receive buffer
ndb/src/common/transporter/TransporterRegistry.cpp:
  Make sure that 
  1) poll_TCP return true if any transporter has data in receiveBuffer
     (previously only if socket had data)
  2) performReceive executes signals if TCP transporter has data in receiveBuffer
     (previously only if data was recevied)
ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
  test, make MAX_RECEIVED_SIGNALS an variable
ndb/test/ndbapi/testNdbApi.cpp:
  testcase
ndb/test/run-test/daily-basic-tests.txt:
  testcase

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28337

is involved.

The Arg_comparator::compare_datetime() comparator caches its arguments if
they are constants i.e. const_item() returns true. The
Item_func_get_user_var::const_item() returns true or false based on
the current query_id and the query_id where the variable was created.
Thus even if a query can change its value its const_item() still will return
true. All this leads to a wrong comparison result when an object of the
Item_func_get_user_var class is involved.

Now the Arg_comparator::can_compare_as_dates() and the
get_datetime_value() functions never cache result of the GET_USER_VAR()
function (the Item_func_get_user_var class).


mysql-test/t/type_datetime.test:
  A test case is added for the bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function
  is involved.
mysql-test/r/type_datetime.result:
  A test case is added for the bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function
  is involved.
sql/item_cmpfunc.cc:
  Bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function
  is involved.
  Now the Arg_comparator::can_compare_as_dates() and the
  get_datetime_value() functions never cache result of the GET_USER_VAR()
  function (the Item_func_get_user_var class).

subqueries in WHERE conditions.
This bug was introduced by the patch for bug 27321.


mysql-test/r/subselect.result:
  Added a test case for bug #28337.
mysql-test/t/subselect.test:
  Added a test case for bug #28337.
sql/item.cc:
  Fixed bug #28337: wrong results for grouping queries with correlated
  subqueries in WHERE conditions.
  This bug was introduced by the patch for bug 27321.
  
  Now in the Item_field::fix_outer_field function we create an Item_outer_ref
  object for an outer reference only if it is used in the SELECT list or
  in the HAVING clause of the subquery against which the reference is resolved.

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/push-5.0

into  mysql.com:/home/hf/work/8663/my50-8663

into  mysql.com:/home/hf/work/8663/my50-8663

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work

into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime

 - Problem was reported as a SP variable using itself as 
   right value inside SUBSTR caused corruption of data. 
 - This bug could not be verified in either 5.0bk or 5.1bk
 - Added test case to prevent future regressions.


mysql-test/r/sp-vars.result:
  Added test case for a reported regression which couldn't be
  verified.
mysql-test/t/sp-vars.test:
  Added test case for a reported regression which couldn't be
  verified.

into  linux-st28.site:/home/martin/mysql/src/5.0o-bug27573


mysql-test/r/func_group.result:
  Auto merged
mysql-test/t/func_group.test:
  bug#27573: hand merged test case

sql/sql_insert.cc:
  Do not access delayed thread memory without a mutex.

into  vajra.(none):/opt/local/work/mysql-5.0-21483


sql/sp_head.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_lex.h:
  Auto merged

Bug#21483 "Server abort or deadlock on INSERT DELAYED with another
implicit insert"
Also fixes and adds test cases for bugs:
20497 "Trigger with INSERT DELAYED causes Error 1165"
21714 "Wrong NEW.value and server abort on INSERT DELAYED to a
table with a trigger".
Post-review fixes.

Problem:
In MySQL INSERT DELAYED is a way to pipe all inserts into a
given table through a dedicated thread. This is necessary for
simplistic storage engines like MyISAM, which do not have internal
concurrency control or threading and thus can not
achieve efficient INSERT throughput without support from SQL layer.
DELAYED INSERT works as follows:
For every distinct table, which can accept DELAYED inserts and has
pending data to insert, a dedicated thread is created to write data
to disk. All user connection threads that attempt to
delayed-insert into this table interact with the dedicated thread in
producer/consumer fashion: all records to-be inserted are pushed
into a queue of the dedicated thread, which fetches the records and 
writes them.
In this design, client connection threads never open or lock
the delayed insert table.
This functionality was introduced in version 3.23 and does not take 
into account existence of triggers, views, or pre-locking.
E.g. if INSERT DELAYED is called from a stored function, which,
in turn, is called from another stored function that uses the delayed
table, a deadlock can occur, because delayed locking by-passes
pre-locking. Besides:
 * the delayed thread works directly with the subject table through
   the storage engine API and does not invoke triggers
 * even if it was patched to invoke triggers, if triggers,
   in turn, used other tables, the delayed thread would
   have to open and lock involved tables (use pre-locking).
 * even if it was patched to use pre-locking, without deadlock
   detection the delayed thread could easily lock out user 
   connection threads in case when the same table is used both
   in a trigger and on the right side of the insert query: 
   the delayed thread would not release locks until all inserts 
   are complete, and user connection can not complete inserts 
   without having locks on the tables used on the right side of the
   query.

Solution:

These considerations suggest two general alternatives for the
future of INSERT DELAYED:
 * it is considered a full-fledged alternative to normal INSERT
 * it is regarded as an optimisation that is only relevant 
   for simplistic engines.
Since we missed our chance to provide complete support of new
features when 5.0 was in development, the first alternative
currently renders infeasible.
However, even the second alternative, which is to detect
new features and convert DELAYED insert into a normal insert, 
is not easy to implement.
The catch-22 is that we don't know if the subject table has triggers
or is a view before we open it, and we only open it in the
delayed thread. We don't know if the query involves pre-locking
until we have opened all tables, and we always first create
the delayed thread, and only then open the remaining tables.
This patch detects the problematic scenarios and converts
DELAYED INSERT to a normal INSERT using the following approach:
 * if the statement is executed under pre-locking (e.g. from
   within a stored function or trigger) or the right
   side may require pre-locking, we detect the situation
   before creating a delayed insert thread and convert the statement
   to a conventional INSERT.
  * if the subject table is a view or has triggers, we shutdown
   the delayed thread and convert the statement to a conventional
   INSERT.


mysql-test/r/insert.result:
  Update test results.
mysql-test/t/insert.test:
  Add a test case for Bug#21483, Bug#20497, Bug#21714 (INSERT DELAYED
  and stored routines, triggers).
sql/sp_head.cc:
  Upgrade lock type to TL_WRITE when computing the pre-locking set.
sql/sql_base.cc:
  Use a new method.
sql/sql_insert.cc:
  INSERT DELAYED and pre-locking:
  - if  under pre-locking, upgrade the lock type to TL_WRITE
  and proceed as a normal write
  - if DELAYED table has triggers, also request a lock upgrade.
  - make sure errors in the delayed thread are propagated
  correctly
sql/sql_lex.h:
  Add a method to check if a parsed tree refers to stored
  routines.

in the case of the overflow in the decimal->integer conversion
we didn't return the proper boundary value, but just the result
of the conversion we calculated on the moment of the error


mysql-test/r/bigint.result:
  bug #8663 cant use bigint unsigned as input to cast
  test result fixed
mysql-test/t/bigint.test:
  bug #8663 cant use bigint unsigned as input to cast
  test case
strings/decimal.c:
  bug #8663 cant use bigint unsigned as input to cast
  decimal->int conversion fixed to return proper boundary value
  in the case of overflow

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug28272

function.

A wrong  condition was used to check that the
Arg_comparator::can_compare_as_dates() function calculated the value of the
string constant. When comparing a non-const STRING function with a constant
DATETIME function it leads to saving an arbitrary value as a cached value of
the DATETIME function.

Now the Arg_comparator::set_cmp_func() function initializes the const_value
variable to the impossible DATETIME value (-1) and this const_value is
cached only if it was changed by the Arg_comparator::can_compare_as_dates()
function.


mysql-test/t/type_datetime.test:
  Added a test case for the bug#28208: Wrong result of a non-const STRING function with a const DATETIME function.
mysql-test/r/type_datetime.result:
  Added a test case for the bug#28208: Wrong result of a non-const STRING function with a const DATETIME function.
sql/item_cmpfunc.cc:
  Bug#28208: Wrong result of a non-const STRING function with a const DATETIME
  function.
  Now the Arg_comparator::set_cmp_func() function initializes the const_value
  variable to the impossible DATETIME value (-1) and this const_value is
  cached only if it was changed by the Arg_comparator::can_compare_as_dates()
  function.

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