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.

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.

merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == ramil@mysql.com-20091215170821-eexh9rqrnw1ruzh2

This fixes two more warnings for tests: 
  - rpl_row_colSize
  - rpl_typeconv

Metadata for geometric fields was not being properly stored by
the slave in its the table definition. This happened because
MYSQL_TYPE_GEOMETRY was not included in the 'switch... case' that
handles field metadata according to the field type. Therefore, it
would default to 0, leading to always have a mismatch between
master's field and slave fields'. 

We fix this by deploying the missing 'case MYSQL_TYPE_GEOMETRY:'.

mysql-test/extra/rpl_tests/type_conversions.test:
  Added some tests for blob fields and also the particular
  case for replicating from/into BLOB into/from GEOMETRY.
sql/field.h:
  As requested by Mats, reverted function added by him in
  changeset:
  http://lists.mysql.com/commits/95313

      
When @@session.binlog_format is modified inside a transaction,
it can cause slave to go out of sync.
      
To fix the problem, make the session variable 'binlog_format' 
read-only inside a transaction.


mysql-test/suite/binlog/r/binlog_format_switch_inside_trans.result:
  Test result for bug#47863.
mysql-test/suite/binlog/t/binlog_format_switch_inside_trans.test:
  Added test file to verify if the session variable 'binlog_format' 
  is read-only inside a transaction and in sub-statements.
sql/set_var.cc:
  Added code to make the session variable 'binlog_format'
  read-only inside a transaction.

This patch fixes these warnings and some compile time warnings.

On top of that, it also fixes rpl_err_ignoredtable test failure.
This test was failing because the warning suppression text was not
matching the latest text. We fix this by making them match.


mysql-test/suite/rpl/t/rpl_err_ignoredtable.test:
  Replaced the suppression text.
sql/rpl_record.cc:
  - Fixed some compile time warnings (replaced %d --> %ld and 
    removed unused mas mask variable.
  - Fixed valgrind warnings when using c_ptr(). Replaced with 
    c_ptr_safe().
sql/rpl_utility.cc:
  - Fixed valgrind warnings when using c_ptr(). Replaced with 
    c_ptr_safe().

Bug#49836 reports that the geometry type does not work
with WL#5151 applied.

The GEOMETRY type inherits the blob comparison function,
which read the pack length from the metadata. The GEOMETRY
type does not fill in the metadata with anything sensible,
so it is always zero, meaning that the pack length for the
source type is considered zero, rendering it always "smaller"
than the target type which has pack length 4 (without pointer).

This patch fixes the problem by defining
Field_geom::pack_length_from_metadata() to always use the
same as Field_geom::row_pack_length().

         when replicating

Post-merge fixes. Updating result files.

         when replicating

The function create_virtual_tmp_table does not
set db_low_byte_first in the same way as
create_tmp_table does, causing copying from
the virtual table to a real table to get strange
values for SET types on big-endian machines.


mysql-test/extra/rpl_tests/type_conversions.test:
  Adding tests for converting between different-sized sets.
sql/sql_select.cc:
  Settng dh_low_byte_first for tables created
  with create_virtual_tmp_table.

The slave thread changed the format of the information it used to
connect to the master after patch for BUG 13963.  This resulted
in old master getting confused, thence rejecting the slave
connection attempt.

In particular, patch for BUG 13963 removed the rpl_recovery_rank
variable which was, at that time, packed together with the rest
of the information which the slave would use to register itself
on the master. Based on this data, the master would then assert
that the number of bytes received in the connection command was
consistent to what it was expecting. 

Therefore, given that a slave, patched with the aforementioned
patch, would not pack the four bytes related to the
rpl_recovery_rank variable, the old master would reject the
connection attempt. It would assume that the data was
inconsistent (fewer bytes than it was expecting) and return 
an error.

We fix this by faking an rpl_recovery_rank variable when
registering the slave on the master. In practice this reverts a
small part of patch for BUG 13963, the one related to the slave
connecting to the master.

sql/repl_failsafe.cc:
  Added bypassing of removed rpl_recovery_rank variable information in
  packet. This should also make more sense when old servers connect
  to a new master (ie, master with patch for BUG 13963). If this was not
  done, the new master could interpert information an old slave sends as
  master_id, when in fact it could be the rpl_recovery_rank data.
sql/slave.cc:
  Faking a rpl_recovery_rank so that we can register as a slave in
  an old master.

merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == build@mysql.com-20091208092611-pbno5awyb0v38hs7

Fixed conflicts in:

- binlog.binlog_unsafe
- rpl.rpl_slow_query_log

Post-merge fixes to update result files.

         replicating

Fixes to make mysqlbinlog work correctly and updates
to rpl_ndb result files.

sql/log_event.cc:
  The processing of the MYSQL_STRING_TYPE is now done
  in table_def::type(), so the support functions for
  mysqlbinlog are changed to work correctly.

Fixes to get it to compile on MacOSX.

Fixing error codes that changed after merge.

NULLable BIGINT and INT columns in comparison

Problem: a consequence of the fix for 43668.
Some Arg_comparator inner initialization missed,
that may lead to unpredictable (wrong) comparison
results.

Fix: always properly initialize Arg_comparator
before its usage.


mysql-test/r/select.result:
  Fix for bug#49517: Inconsistent behavior while using 
  NULLable BIGINT and INT columns in comparison
    -test result.
mysql-test/t/select.test:
  Fix for bug#49517: Inconsistent behavior while using 
  NULLable BIGINT and INT columns in comparison
    -test case.
sql/item_cmpfunc.cc:
  Fix for bug#49517: Inconsistent behavior while using 
  NULLable BIGINT and INT columns in comparison
    - now all Arg_comparator::set_cmp_func() set
  Arg_comparator::set_null to ensure its proper initialization
  in all cases (by default it's set to TRUE in constructors).
sql/item_cmpfunc.h:
  Fix for bug#49517: Inconsistent behavior while using 
  NULLable BIGINT and INT columns in comparison
    - now all Arg_comparator::set_cmp_func() set
  Arg_comparator::set_null to ensure its proper initialization
  in all cases (by default it's set to TRUE in constructors).

           for InnoDB

The class Field_bit_as_char stores the metadata for the
field incorrecly because bytes_in_rec and bit_len are set
to (field_length + 7 ) / 8 and 0 respectively, while
Field_bit has the correct values field_length / 8 and
field_length % 8.

Solved the problem by re-computing the values for the
metadata based on the field_length instead of using the
bytes_in_rec and bit_len variables.

To handle compatibility with old server, a table map
flag was added to indicate that the bit computation is
exact. If the flag is clear, the slave computes the
number of bytes required to store the bit field and
compares that instead, effectively allowing replication
*without conversion* from any field length that require
the same number of bytes to store.

mysql-test/suite/rpl/t/rpl_typeconv_innodb.test:
  Adding test to check compatibility for bit field
  replication when using InnoDB.
sql/field.cc:
  Extending compatible_field_size() with flags from
  table map to allow fields to check master info.
sql/field.h:
  Extending compatible_field_size() with flags from
  table map to allow fields to check master info.
sql/log.cc:
  Removing table map flags since they are not used
  outside table map class.
sql/log_event.cc:
  Removing flags parameter from table map constructor
  since it is not used and does not have to be exposed.
sql/log_event.h:
  Adding flag to denote that bit length for bit field type
  is exact and not potentially rounded to even bytes.
sql/rpl_utility.cc:
  Adding fields to table_def to store table map flags.
sql/rpl_utility.h:
  Removing obsolete comment and adding flags to store
  table map flags from master.

  was killed

Merge the fix from 5.1-bugteam to 5.1-main

Merge the fix from 5.1-bugteam to 5.1-main

Merge the fix from 5.1-bugteam to 5.1-main

Fixing minor error when printing SQL types from master and cleaning some code.

Updating result files.

Problem: The test was written before BUG#45827 was fixed.
The test contained code that assumed the wrong behavior,
pre-BUG#45827. Then, the fix for BUG#45827 was merged
from 5.1-rep+2 to 5.1-rep+3. Since the test case assumed
the wrong behavior, it failed. This should have been fixed
by making the test assume the correct behavior, but was
fixed by updating the result file to assert failure.
Fix 1: fix the test to assume correct behavior
(post-BUG#45827), update result file.
Fix 2: make test fail with 'die' instead of 'exit' when
wrong behavior is detected. Thus, the test cannot be
silenced with a wrong result file in case the behavior
will change again.


mysql-test/extra/rpl_tests/create_recursive_construct.inc:
  Replaced 'exit' by 'die' to avoid similar
mysql-test/suite/binlog/r/binlog_unsafe.result:
  Updated result file.
mysql-test/suite/binlog/t/binlog_unsafe.test:
  Since BUG#45827 is now fixed, we need to update the test case
  in two places where it expects the wrong result because of
  BUG#45827.