Bug #45856  	can't switch from binlog_format=row to mix with open tmp tbl


If binlog_format=MIXED, there are open temporary tables, an unsafe statement
is executed, and the user issues 'SET @@session.binlog_format = STATEMENT',
then subsequent DML statements will be written in row format despite 
binlog_format=STATEMENT. Because the binlog format can't be reset to
statement based by 'reset_current_stmt_binlog_row_based' function.

If binlog_format=ROW, there are open temporary tables, and an unsafe statement
is executed, then the statement 'SET @@session.binlog_format = MIXED' generates
the error:
"Cannot switch out of the row-based binary log format when the session has open
temporary tables"
However, it is safe to switch to MIXED mode because events in row format are allowed.


To fix the above two problems, generate ER_TEMP_TABLE_PREVENTS_SWITCH_OUT_OF_RBR
and forbid switching from MIXED or ROW to STATEMENT when there are open temp
tables and we are logging in row format. There is no error in any other case.


mysql-test/suite/binlog/r/binlog_format_switch_in_tmp_table.result:
  Test result for bug#45855 and bug#45856.
mysql-test/suite/binlog/t/binlog_format_switch_in_tmp_table.test:
  Added test file to verify if the program will generate
  ER_TEMP_TABLE_PREVENTS_SWITCH_OUT_OF_RBR error and forbid
  switching from MIXED or ROW to STATEMENT when there are
  open temp tables and we are logging in row format. There
  is no error in any other case.

STMT mode aborts the SQL Thread if it receives changes in ROW mode and such
changes are not processed.

         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().

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.