into  outpost.site:/home/cps/mysql/trees/5.1-runtime-bug9191

into  outpost.site:/home/cps/mysql/trees/5.0-runtime-bug9191

into  mysql.com:/home/cps/mysql/trees/5.1-runtime-bug9191

into  mysql.com:/home/cps/mysql/trees/5.0-runtime-bug9191

(4.1 version, with post-review fixes)
  
  The fix for another Bug (6439) limited FROM_UNIXTIME() to
  TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT,
  however unix timestamp in general is not considered to be limited 
  by this value. All dates up to power(2,31)-1 are valid.
  
  This patch extends allowed TIMESTAMP range so, that max
  TIMESTAMP value is power(2,31)-1. It also corrects
  FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that
  max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME()
  is fixed accordingly to allow conversion of dates up to
  2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ()
  function to allow extended range of dates.
  
  The main problem solved in the patch is possible overflows
  of variables, used in broken-time representation to time_t
  conversion (required for UNIX_TIMESTAMP).

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug22584

a updatable view.

When there's a VIEW on a base table that have AUTO_INCREMENT column, and
this VIEW doesn't provide an access such column, after INSERT to such
VIEW LAST_INSERT_ID() did not return the value just generated.

This behaviour is intended and correct, because if the VIEW doesn't list
some columns then these columns are effectively hidden from the user,
and so any side effects of inserting default values to them.

However, there was a bug that such statement inserting into a view would
reset LAST_INSERT_ID() instead of leaving it unchanged.

This patch restores the original value of LAST_INSERT_ID() instead of
resetting it to zero.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug18819

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug18819

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819

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.

into  mysql.com:/home/cps/mysql/devel/5.1-rename-bug

into  alik.:/mnt/raid/alik/MySQL/devel/5.1-rt-bug17486

The problem was that IM stoped guarded instances on shutdown,
but didn't wait for them to stop.

The fix is to wait for guarded instances to stop before exitting
from the main thread.

The idea is that Instance-monitoring thread should add itself
to Thread_registry so that it will be taken into account on shutdown.
However, Thread_registry should not signal it on shutdown in order to
not interrupt wait()/waitpid().

into  mysql.com:/home/cps/mysql/devel/5.1-rename-bug

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg15228-2

into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg15228

warnings in sql_trigger.cc and sql_view.cc".

According to the current version of C++ standard offsetof() macro
can't be used for non-POD types. So warnings were emitted when we
tried to use this macro for TABLE_LIST and Table_triggers_list
classes. Note that despite of these warnings it was probably safe
thing to do.

This fix tries to circumvent this limitation by implementing
custom version of offsetof() macro to be used with these
classes. This hack should go away once we will refactor
File_parser class.

Alternative approaches such as disabling this warning for
sql_trigger.cc/sql_view.cc or for the whole server were
considered less explicit. Also I was unable to find a way
to disable particular warning for particular _part_ of
file in GCC.

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt

  merge fixes

This patch reverts a change introduced by Bug 6951, which incorrectly
set thd->abort_on_warning for stored procedures.

As per internal discussions about the SQL_MODE=TRADITIONAL,
the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE
trigger.

Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE
have been included or revised, to reflect the intended behavior.

(reposting approved patch, to work around source control issues, no review needed)

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.1-engines

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1-opt