Conflicts:
  Text conflict in sql/log.cc
  Text conflict in sql/slave.cc
  Text conflict in sql/sql_base.cc

         replicating

Replace c_ptr() calls with c_ptr_safe() calls to
avoid valgrind warnings.

Adding code to to handle the case that no metadata
was present in the table map for the column.

Allow first parameter to unpack_row() to be NULL,
in which case no source tables is used and hence
no checks nor conversions are done.

Clarifying some comments and fixing documentation
for unpack_row().

run in PB2 as it ought to be. Otherwise test will fail because
variable is no recognized:

1193: Unknown system variable 'slave_type_conversions'

  - mysqld--help-win
    Updated result so that it contains missing
    value for slave-type-conversions

  - rpl_idempotency
    This seems a bad merge. In BUG#39934, the contents of
    this file had been split into rpl_row_idempontency and
    rpl_idempotency. The patch was pushed to 5.1-rep+3 which
    was later merged in rep+2-delivery1 which in turn was
    merged in 5.1-rpl-merge. Now while merging next-mr in
    5.1-rpl-merge, the file got back it's old content (which
    is in rpl_row_idempotency now because of BUG#39934). This
    cset reverts the bad merge:

    bzr merge -r revid:dao-gang.qu@sun.com-20100112120709-ioxp11yl9bvquaqd..\
    before:revid:dao-gang.qu@sun.com-20100112120709-ioxp11yl9bvquaqd\
    suite/rpl/t/rpl_idempotency.test

  - sys_vars.rpl_init_slave_func
    Added suppression for the unsafe warning.

 - sys_vars.all_vars:
   Added test case for slave_type_conversions variable
 - rpl_row_idempotency
   Removed ER_SLAVE_AMBIGOUS_EXEC_MODE (which was removed by WL 4738)
   from the test case. Using ER_WRONG_VALUE_FOR_VAR instead.
 - mysqld--help-win
   Added missing help for --slave-type-conversions from the
   result file.
     

Original revision:
------------------------------------------------------------
revno: 3817
revision-id: guilhem@mysql.com-20100108092756-k0zzf4kvx9b7bh38
parent: guilhem@mysql.com-20100107101133-hrrgcdqg508runuf
committer: Guilhem Bichot <guilhem@mysql.com>
branch nick: mysql-6.0-codebase-bugfixing
timestamp: Fri 2010-01-08 10:27:56 +0100
message:
  fix for BUG#50120 "Valgrind errors in any test, inside mysqltest"
  Problem was that as v->name[v->name_len] may be uninitialized (which is ok per se),
  it shouldn't be used in an if(). We remove this zero_the_char/restore_it logic by
  rather zero-terminating the v->name string when we create it in var_init().
------------------------------------------------------------

Original revision:

------------------------------------------------------------
revno: 3789.1.9
revision-id: serg@mysql.com-20091229134448-phe834ukzmi0k2e3
parent: serg@mysql.com-20091227081418-bgfg952gzumn1k3h
committer: Sergei Golubchik <serg@mysql.com>
branch nick: 6.0-codebase
timestamp: Tue 2009-12-29 14:44:48 +0100
message:
  better fix for Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds
  
  use setenv instead of putenv
------------------------------------------------------------

The test case did not start with fresh binlogs, so in some
cases, dependending on the order MTR runs the tests, it would
try to show binlog contents from invalid positions (binary log
would contain unexpected events from previous test).

We fix this by deploying a RESET MASTER at the beginning of the
test case.

Conflicts:

Text conflict in .bzr-mysql/default.conf
Text conflict in mysql-test/extra/rpl_tests/rpl_loaddata.test
Text conflict in mysql-test/r/mysqlbinlog2.result
Text conflict in mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
Text conflict in mysql-test/suite/binlog/r/binlog_unsafe.result
Text conflict in mysql-test/suite/rpl/r/rpl_insert_id.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result
Text conflict in mysql-test/suite/rpl/r/rpl_udf.result
Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test
Text conflict in sql/field.h
Text conflict in sql/log.cc
Text conflict in sql/log_event.cc
Text conflict in sql/log_event_old.cc
Text conflict in sql/mysql_priv.h
Text conflict in sql/share/errmsg.txt
Text conflict in sql/sp.cc
Text conflict in sql/sql_acl.cc
Text conflict in sql/sql_base.cc
Text conflict in sql/sql_class.h
Text conflict in sql/sql_db.cc
Text conflict in sql/sql_delete.cc
Text conflict in sql/sql_insert.cc
Text conflict in sql/sql_lex.cc
Text conflict in sql/sql_lex.h
Text conflict in sql/sql_load.cc
Text conflict in sql/sql_table.cc
Text conflict in sql/sql_update.cc
Text conflict in sql/sql_view.cc
Conflict adding files to storage/innobase.  Created directory.
Conflict because storage/innobase is not versioned, but has versioned children.  Versioned directory.
Conflict adding file storage/innobase.  Moved existing file to storage/innobase.moved.
Conflict adding files to storage/innobase/handler.  Created directory.
Conflict because storage/innobase/handler is not versioned, but has versioned children.  Versioned directory.
Contents conflict in storage/innobase/handler/ha_innodb.cc

Part IV: sql instrumentation

WL#5151 was pushed.

Problem 1: Some old binlog events do not contain metadata. This
makes checking whether the field can be converted or not rather
impossible because one cannot compare, for instance, field sizes
from original table and target table.

Solution 1: When an event does not contain metadata, we will just
check if field types are equal and assume that original field
definition matched with the one in the target table.

Problem 2: There is a second fix, which involves lack of
information regarding maybe_null. This was causing a conditional
jump warning when creating a conversion table. 

Solution 2: We will just assume that all fields that need to be
in the conversion table may be null.

Subtraction of two unsigned months yielded a (very large) positive value.
Conversion of this to a signed value was not necessarily well defined.

Solution: do the subtraction on signed values.

eliminate 3 more "directory path" variables from the test's output (it was already
the case for other similar ones likes slow-query-log-file).

"set engine_condition_pushdown" is deprecated, engine condition pushdown is controlled
by a new "set optimizer_switch=engine_condition_pushdown=on|off".

fixing wrong indentation in two Makefile.am, which prevented the Anjuta IDE from parsing the MySQL tree.

In auto-commit mode, updating both trx and non-trx tables (i.e. issuing a mixed
statement) causes the following sequence of events:

1 - "Flush trx changes" (MYSQL_BIN_LOG::write) - T1:
  1.1 - mutex_lock (&LOCK_log)
  1.2 - mutex_lock (&LOCK_prep_xids)
  1.3 - increase prepared_xids
  1.4 - mutex_unlock (&LOCK_prep_xids)
  1.5 - mutex_unlock (&LOCK_log)

2 - "Flush non-trx changes" (MYSQL_BIN_LOG::write) - T1:
  2.1 - mutex_lock (&LOCK_log)
  2.2 - mutex_unlock (&LOCK_log)

3. "unlog" - T1
  3.1 - mutex_lock (&LOCK_prep_xids)
  3.2 - decrease prepared xids
  3.3 - pthread_cond_signal(&COND_prep_xids);
  3.4 - mutex_unlock (&LOCK_prep_xids)

The "FLUSH logs" command produces the following sequence of events:

1 - "FLUSH logs" command (MYSQL_BIN_LOG::new_file_impl) - user thread:
  1.1 - mutex_lock (&LOCK_log)
  1.2 - mutex_lock (&LOCK_prep_xids)
  1.3 - while (prepared_xids)  pthread_cond_wait(..., &LOCK_prep_xids);
  1.4 - mutex_unlock (&LOCK_prep_xids)
  1.5 - mutex_unlock (&LOCK_log)

A deadlock will arise if T1 flushes the trx changes and thus increases
prepared_xids but before it is able to continue the execution and flush the
non-trx changes, an user thread calls the "FLUSH logs" command and wait that
the prepared_xids is decreased and gets to zero. However, T1 cannot proceed
with the call to "Flush non-trx changes" because it will block in the mutex
"LOCK_log" and by consequence cannot complete the execution and call the
unlog to decrease the prepared_xids.

To fix the problem, we ensure that the non-trx changes are always flushed
before the trx changes.

Note that if you call "Flush non-trx changes" and a concurrent "FLUSH logs" is
issued, the "Flush non-trx changes" may block, but a deadlock will never happen
because the prepared_xids will eventually get to zero. Bottom line, there will
not be any transaction able to increase the prepared_xids because they will
block in the mutex "LOCK_log" (MYSQL_BIN_LOG::write) and those that increased
the prepared_xids will eventually commit and decrease the prepared_xids.

           subquery in the select list
      
When a dependent subquery with count(distinct <col>) was 
evaluated multiple times, the Distinct_Aggregator was reused. 
However, the Aggregator was not reset, so when the subquery was
evaluated for the next record in the outer select, old dependent
info was used.
      
The fix is to clear() the existing aggregator in 
Item_sum::set_aggregator(). This ensures that the aggregator is
reevaluated with the new dependent information.

 
- backported code that handles %f/%g arguments in 
my_vsnprintf.c from 6.0 
- backported %f/%g tests in unittest/mysys/my_vsnprintf-t.c 
from 6.0 
- replaced snprintf("%g") in sql/set_var.cc with my_gcvt() 
- removed unnecessary "--replace-result"s for Windows in 
mysql-test/suite/sys_vars/t/long_query_time_basic.test 
- some test results adjustments