mysql-test/r/rpl_switch_stm_row_mixed.result:
  post-merge fix
mysql-test/t/rpl_switch_stm_row_mixed.test:
  post-merge fix (and no need to use a table t12 in some place).

into  gbichot3.local:/home/mysql_src/mysql-5.1


mysql-test/t/disabled.def:
  Auto merged
sql/set_var.cc:
  Auto merged
sql/sql_class.h:
  Auto merged
mysql-test/r/rpl_switch_stm_row_mixed.result:
  manual merge (will fix)
mysql-test/t/rpl_switch_stm_row_mixed.test:
  manual merge (will fix)

mysql-test/extra/binlog_tests/mix_innodb_myisam_binlog.test:
  As in other tests, we should replace both position columns of SHOW BINLOG
  EVENTS; otherwise a small change (like here, the fact that CREATE TEMPORARY
  TABLE is not binlogged in RBR as a consequence of the bugfix for BUG#20522)
  causes a large diff in the result file.
mysql-test/r/binlog_row_mix_innodb_myisam.result:
  result update: positions in SHOW BINLOG EVENTS become #, and
  the CREATE TEMPORARY TABLE disappear from binlog (consequence of fix for
  BUG#20522 "RBR: CREATE TEMPORARY TABLE SELECT writes to binlog though
  unneeded").

mysql-test/r/rpl_switch_stm_row_mixed.result:
  result update.
  I noticed the appearance of an additional table_map+rows in the binlog
  when INSERT DELAYED, since I pulled the latest fixes to RBR of 
  INSERT DELAYED. This is ok, I put the reason why into sql_insert.cc.
sql/sql_insert.cc:
  A comment about the new row-based binlogging of INSERT DELAYED.
  Removing duplicate MY_HOOKS (from a wrong merge of the past??).

into  gbichot3.local:/home/mysql_src/mysql-5.1


sql/sql_insert.cc:
  Auto merged

were copied/split between 5.0 and 5.1).


mysql-test/extra/rpl_tests/rpl_auto_increment.test:
  manual merge of test from 5.0
mysql-test/extra/rpl_tests/rpl_insert_id.test:
  manuel merge of test from 5.0
mysql-test/r/rpl_auto_increment.result:
  error messages changed compared to 5.0

into  gbichot3.local:/home/mysql_src/mysql-5.1


mysql-test/r/rpl_auto_increment.result:
  Auto merged
mysql-test/r/rpl_insert_id.result:
  Auto merged
mysql-test/t/rpl_openssl.test:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
mysql-test/t/rpl_auto_increment.test:
  will fix by hand
mysql-test/t/rpl_insert_id.test:
  will fix by hand
sql/handler.cc:
  comment
sql/handler.h:
  manual merge
sql/sql_insert.cc:
  manual merge

1) Fix for BUG#19630 "stored function inserting into two auto_increment breaks
statement-based binlog":
a stored function inserting into two such tables may fail to replicate
(inserting wrong data in the slave's copy of the second table) if the slave's
second table had an internal auto_increment counter different from master's.
Because the auto_increment value autogenerated by master for the 2nd table
does not go into binlog, only the first does, so the slave lacks information.
To fix this, if running in mixed binlogging mode, if the stored function or
trigger plans to update two different tables both having auto_increment
columns, we switch to row-based for the whole function.
We don't have a simple solution for statement-based binlogging mode, there
the bug remains and will be documented as a known problem.
Re-enabling rpl_switch_stm_row_mixed.
2) Fix for BUG#20630 "Mixed binlogging mode does not work with stored
functions, triggers, views", which was a documented limitation (in mixed
mode, we didn't detect that a stored function's execution needed row-based
binlogging (due to some UUID() call for example); same for
triggers, same for views (a view created from a SELECT UUID(), and doing
INSERT INTO sometable SELECT theview; would not replicate row-based).
This is implemented by, after parsing a routine's body, remembering in sp_head
that this routine needs row-based binlogging. Then when this routine is used,
the caller is marked to require row-based binlogging too.
Same for views: when we parse a view and detect that its SELECT needs
row-based binary logging, we mark the calling LEX as such.
3) Fix for BUG#20499 "mixed mode with temporary table breaks binlog":
a temporary table containing e.g. UUID has its changes not binlogged,
so any query updating a permanent table with data from the temporary table
will run wrongly on slave. Solution: in mixed mode we don't switch back
from row-based to statement-based when there exists temporary tables.
4) Attempt to test mysqlbinlog on a binlog generated by mysqlbinlog;
impossible due to BUG#11312 and BUG#20329, but test is in place for when
they are fixed.


mysql-test/r/rpl_switch_stm_row_mixed.result:
  testing BUG#19630 "stored function inserting into two auto_increment breaks
  statement-based binlog",
  testing BUG#20930 "Mixed binlogging mode does not work with stored functions,
  triggers, views.
  testing BUG#20499 "mixed mode with temporary table breaks binlog".
  I have carefully checked this big result file, it is correct.
mysql-test/t/disabled.def:
  re-enabling test
mysql-test/t/rpl_switch_stm_row_mixed.test:
  Test for BUG#19630 "stored function inserting into two auto_increment breaks
  statement-based binlog":
  we test that it goes row-based, but only when needed;
  without the bugfix, master and slave's data differed.
  Test for BUG#20499 "mixed mode with temporary table breaks binlog":
  without the bugfix, slave had 2 rows, not 3.
  Test for BUG#20930 "Mixed binlogging mode does not work with stored
  functions, triggers, views".
  Making strings used more different, for easier tracking of "by which routine
  was this binlog line generated".
  Towards the end, an attempt to test mysqlbinlog on a binlog generated by
  the mixed mode; attempt failed because of BUG#11312 and BUG#20929.
sql/item_create.cc:
  fix for build without row-based replication
sql/set_var.cc:
  cosmetic: in_sub_stmt is exactly meant to say if we are in stored
  function/trigger, so better use it.
sql/sp.cc:
  When a routine adds its tables to the top statement's tables, if this routine
  needs row-based binlogging, mark the entire top statement as well.
  Same for triggers.
  Needed for making the mixed replication mode work with stored functions
  and triggers.
sql/sp_head.cc:
  new enum value for sp_head::m_flags, remembers if, when parsing the 
  routine, we found at least one element (UUID(), UDF) requiring row-based
  binlogging.
sql/sp_head.h:
  new enum value for sp_head::m_flags (see sp_head.cc).
  An utility method, intended for attributes of a routine which need
  to propagate upwards to the caller; so far only used for binlogging
  information, but open to any other attribute.
sql/sql_base.cc:
  For BUG#19630 "stored function inserting into two auto_increment
  breaks statement-based binlog":
  When we come to locking tables, we have collected all tables used by
  functions, views and triggers, we detect if we're going to update two tables
  having auto_increment columns. If yes, statement-based binlogging won't work
  (Intvar_log_event records only one insert_id) so, if in mixed binlogging
  mode, switch to row-based.
  For making mixed mode work with stored functions using UUID/UDF:
  when we come to locking tables, we have parsed the whole body so know if
  some elements need row-based. Generation of row-based binlog events
  depends on locked tables, so this is the good place to decide of the binlog
  format.
sql/sql_class.h:
  Fix for BUG#20499 "mixed mode with temporary table breaks binlog".
  Making mixed mode work with stored functions/triggers: don't reset
  back to statement-based if in executing a stored function/trigger.
sql/sql_lex.cc:
  fix for build without row-based replication.
  binlog_row_based_if_mixed moves from st_lex to Query_tables_list, because
  that boolean should not be affected when a SELECT reads the INFORMATION_SCHEMA
  and thus implicitely parses a view or routine's body: this body may
  contain needing-row-based components like UUID() but the SELECT on
  INFORMATION_SCHEMA should not be affected by that and should not use
  row-based; as Query_tables_list is backed-up/reset/restored when parsing
  the view/routine's body, so does binlog_row_based_if_mixed and the
  top SELECT is not affected.
sql/sql_lex.h:
  fix for build without row-based replication.
  binlog_row_based_if_mixed moves from st_lex to Query_tables_list
  (see sql_lex.cc)
sql/sql_parse.cc:
  For the mixed mode to work with stored functions using UUID and UDF, we need
  to move the switch-back-from-row-to-statement out of
  mysql_execute_command() (which is executed for each statement, causing
  the binlogging mode to change in the middle of the function, which would
  not work)
  The switch to row-based is now done in lock_tables(), no need to keep it
  in mysql_execute_command(); in lock_tables() we also switch back from 
  row-based to statement-based (so in a stored procedure, all statements
  have their binlogging mode). We must however keep a resetting in
  mysql_reset_thd_for_next_command() as e.g. CREATE PROCEDURE does not call
  lock_tables().
sql/sql_view.cc:
  When a view's body needs row-based binlogging (e.g. the view is created
  from SELECT UUID()), propagate this fact to the top st_lex.
sql/sql_yacc.yy:
  use TRUE instead of 1, for binlog_row_based_if_mixed.

Fixing typo and potential memory problem.
Reducing number of concurrent mysqlslap threads since tests fail
in pushbuild due to too many threads.


mysql-test/r/rpl_insert.result:
  Result change.
mysql-test/t/rpl_insert.test:
  Reducing number of threads since it doesn't pass pushbuild.
sql/sql_insert.cc:
  Fixing typo and potential memory problem.

mysys/my_malloc.c:
  Changing prototype for my_strndup().
server-tools/instance-manager/parse.h:
  Changing prototype for my_strndup().

Previous patch didn't work: moving variable settings inside critical region.


sql/slave.cc:
  Moving variable setting inside critical region (again) when
  terminating slave I/O thread.

into  romeo.(none):/home/bk/b20821-mysql-5.1-new-rpl

in pushbuild on Replication/Backup team tree.


include/my_sys.h:
  Using "char" instead of "byte" for my_strndup().
mysys/safemalloc.c:
  Using "char" instead of "byte" for my_strndup().

into  romeo.(none):/home/bkroot/mysql-5.1-new-rpl

into  eucla.lemis.com:/home/MySQL/5.1-Bug-20850

  BUG#20850: Assert during slave shutdown in many rpl_* tests.
  This was caused by a race condition at the end of handle_slave_io
  which under some circumstances allowed the cleanup to proceed before
  the thread had completed.


sql/slave.cc:
  BUG#20850: Assert during slave shutdown in many rpl_* tests.
  This was caused by a race condition at the end of handle_slave_io
  which under some circumstances allowed the cleanup to proceed before
  the thread had completed.

  Tidy up white space.


sql/slave.cc:
  Tidy up white space.

mysql-test/t/rpl_insert.test:
  Adding sleep to allow mysqlslap to finish.

statement-based" (bugfix was committed today):
we verify that now it works in mixed mode. And a comment.


mysql-test/r/rpl_switch_stm_row_mixed.result:
  result update
mysql-test/t/rpl_switch_stm_row_mixed.test:
  testcase for BUG#20633
sql/sql_insert.cc:
  the #ifdef was not necessary; a comment.

mysql_client_test like mysql-test-run". Nothing to document.


mysql-test/mysql-test-run.pl:
  if --debug, add debugging of mysql_client_test (useful at least to know what
  insert_id values it receives in the ok packets of INSERT).

into  gbichot3.local:/home/mysql_src/mysql-5.1-new-WL3146-handler


mysql-test/mysql-test-run.pl:
  Auto merged
mysql-test/r/rpl_row_create_table.result:
  Auto merged
mysql-test/t/rpl_row_create_table.test:
  Auto merged
sql/sql_class.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged

The bug was that if the server was running in mixed binlogging mode,
and an INSERT DELAYED used some needing-row-based components like UUID(),
the server didn't binlog this row-based but statement-based, which
thus failed to insert correct data on the slave.
This changeset implements that when a delayed_insert thread is created,
if the server's global binlog mode is "mixed", that thread will use row-based.
This also fixes BUG#20633 "INSERT DELAYED RAND() or @user_var does not
replicate statement-based": we don't fix it in statement-based mode (would
require bookeeping of rand seeds and user variables used by each row),
but at least it will now work in mixed mode (as row-based will be used).
We re-enable rpl_switch_stm_row_mixed.test (so BUG#18590
which was about re-enabling this test, will be closed) to test the fixes.
Between when it was disabled and now, some good changes to row-based
binlogging (no generation of table map events for non-changed tables)
induce changes in the test's result file.


mysql-test/r/rpl_switch_stm_row_mixed.result:
  result update.
  Note that some pieces of binlog are gone, not due to my test but to changes
  to the row-based binlogging code (non-changed tables don't generate
  table map binlog events now) done while the test was disabled.
mysql-test/t/disabled.def:
  this test works now
mysql-test/t/rpl_switch_stm_row_mixed.test:
  testing fix to make INSERT DELAYED work in mixed mode
sql/sql_insert.cc:
  In mixed binlogging mode, the delayed_insert system thread now always
  uses row-based binlogging.
  This makes replication of INSERT DELAYED VALUES(RAND()) or VALUES(@A)
  work in mixed mode (it does not in statement-based).

by default we never run disabled tests (even if they're
explicitely listed on the command-line). We add an option --enable-disabled
which will run tests even though they are disabled, and will print, for each
such test, the comment explaining why it was disabled.
The reason for the change is when you want to run "all tests which are about
NDB" for example: mysql-test-run.pl t/*ndb*.test used to run some disabled
NDB tests, causing failures, causing investigations.
Code amended and approved by Kent.


mysql-test/lib/mtr_cases.pl:
  always detect if a test is listed as disabled, and read the comment why is is.
  If it is listed, don't run the test, except if
  --enable-disabled was given, then mark the test as to-run-even-
  though-it-is-listed-as-disabled.
mysql-test/lib/mtr_report.pl:
  Report tests which will run though they are listed as disabled
  (does something only if --enable-disabled).
mysql-test/mysql-test-run.pl:
  New behaviour: by default we never run disabled tests (even if they're
  explicitely listed on the command-line). We add an option --enable-disabled
  which will run tests even though they are disabled, and will print, for each
  such test, the comment explaining why it was disabled.

into  gbichot3.local:/home/mysql_src/mysql-5.0

into  gbichot3.local:/home/mysql_src/mysql-5.0


sql/handler.cc:
  Auto merged
sql/handler.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged

a too large value": the bug was that if MySQL generated a value for an
auto_increment column, based on auto_increment_* variables, and this value
was bigger than the column's max possible value, then that max possible
value was inserted (after issuing a warning). But this didn't honour
auto_increment_* variables (and so could cause conflicts in a master-master
replication where one master is supposed to generated only even numbers,
and the other only odd numbers), so now we "round down" this max possible
value to honour auto_increment_* variables, before inserting it.


mysql-test/r/rpl_auto_increment.result:
  result update. Before the fix, the result was that master inserted 127 in t1
  (which didn't honour auto_increment_* variables!),
  instead of failing with "duplicate key 125" like now.
mysql-test/t/rpl_auto_increment.test:
  Test for BUG#20524 "auto_increment_* not observed when inserting
  a too large value".
  We also check the pathological case (table t2) where it's impossible to
  "round down".
  The fixer of BUG#20573 will be able to use table t2 for testing his fix.
sql/handler.cc:
  If handler::update_auto_increment() generates a value larger than the field's
  max possible value, we used to simply insert this max possible value
  (after pushing a warning). Now we "round down" this max possible value to
  honour auto_increment_* variables (if at all possible), before trying the
  insertion.

mysql-test/t/rpl_insert.test:
  Fixing to use INSERT DELAYED.

into  mysql.com:/home/bk/b20821-mysql-5.1-new-rpl


sql/sql_class.cc:
  Auto merged
sql/sql_insert.cc:
  Auto merged

Reverting to old behaviour of writing the query before all rows
have been written.


mysql-test/r/rpl_row_delayed_ins.result:
  Result change
sql/sql_class.cc:
  Adding debug message to binlog_query()
sql/sql_insert.cc:
  - Changing write_delayed() to use a LEX_STRING for the query.
  - Adding query string to class delayed_row.
  - Removing query string from class delayed_insert.
  - Adding code to copy query string and delete it when the row
    is executed.
  - Logging query at first row instead of after all rows are 
    inserted (reverting to old behaviour).
  - Flushing the pending row event after all rows have been inserted.
    This is necessary since binlog_query() is called before all rows
    instead of after.
mysql-test/r/rpl_insert.result:
  New BitKeeper file ``mysql-test/r/rpl_insert.result''
mysql-test/t/rpl_insert.test:
  New BitKeeper file ``mysql-test/t/rpl_insert.test''

auto_increment breaks binlog":
if slave's table had a higher auto_increment counter than master's (even
though all rows of the two tables were identical), then in some cases,
REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate
statement-based (it inserted different values on slave from on master).
write_record() contained a "thd->next_insert_id=0" to force an adjustment
of thd->next_insert_id after the update or replacement. But it is this
assigment introduced indeterminism of the statement on the slave, thus
the bug. For ON DUPLICATE, we replace that assignment by a call to
handler::adjust_next_insert_id_after_explicit_value() which is deterministic
(does not depend on slave table's autoinc counter). For REPLACE, this
assignment can simply be removed (as REPLACE can't insert a number larger
than thd->next_insert_id).
We also move a too early restore_auto_increment() down to when we really know
that we can restore the value.


mysql-test/r/rpl_insert_id.result:
  result update, without the bugfix, slave's "3 350" were "4 350".
mysql-test/t/rpl_insert_id.test:
  test for BUG#20188 "REPLACE or ON DUPLICATE KEY UPDATE in
  auto_increment breaks binlog".
  There is, in this order:
  - a test of the bug for the case of REPLACE
  - a test of basic ON DUPLICATE KEY UPDATE functionality which was not
  tested before
  - a test of the bug for the case of ON DUPLICATE KEY UPDATE
sql/handler.cc:
  the adjustment of next_insert_id if inserting a big explicit value, is
  moved to a separate method to be used elsewhere.
sql/handler.h:
  see handler.cc
sql/sql_insert.cc:
  restore_auto_increment() means "I know I won't use this autogenerated
  autoincrement value, you are free to reuse it for next row". But we were
  calling restore_auto_increment() in the case of REPLACE: if write_row() fails
  inserting the row, we don't know that we won't use the value, as we are going to
  try again by doing internally an UPDATE of the existing row, or a DELETE
  of the existing row and then an INSERT. So I move restore_auto_increment()
  further down, when we know for sure we failed all possibilities for the row.
  Additionally, in case of REPLACE, we don't need to reset THD::next_insert_id:
  the value of thd->next_insert_id will be suitable for the next row.
  In case of ON DUPLICATE KEY UPDATE, resetting thd->next_insert_id is also
  wrong (breaks statement-based binlog), but cannot simply be removed, as
  thd->next_insert_id must be adjusted if the explicit value exceeds it.
  We now do the adjustment by calling
  handler::adjust_next_insert_id_after_explicit_value() (which, contrary to
  thd->next_insert_id=0, does not depend on the slave table's autoinc counter,
  and so is deterministic).

into  mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl

 Disabling 'rpl_openssl'.


mysql-test/t/rpl_openssl.test:
  Disabling 'rpl_openssl'.

 Enabling rpl_openssl.test for Windows to check that
 currently it still hangs (because I can't reproduce
 this on my machine).


mysql-test/t/rpl_openssl.test:
  Enabling rpl_openssl.test for Windows

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge


sql/ha_ndbcluster.cc:
  Auto merged

into  dator5.(none):/home/pappa/bug17138


sql/item_sum.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_update.cc:
  Auto merged

into  dator5.(none):/home/pappa/bug17138


mysql-test/r/partition.result:
  manual merge
mysql-test/t/partition.test:
  manual merge

into  dator5.(none):/home/pappa/bug20583


mysql-test/r/partition.result:
  Auto merged
mysql-test/t/partition.test:
  Auto merged
sql/ha_partition.cc:
  Auto merged

into  dator5.(none):/home/pappa/bug17138


BUILD/compile-pentium-gcov:
  Auto merged
sql/ha_ndbcluster.h:
  Auto merged
sql/handler.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged