The thd->variables.option_bits & OPTION_BIN_LOG is currently abused: 
it's both a system variable and an implementation switch. The current
approach to this option bit breaks the session variable encapsulation. 
      
Besides it is allowed to change @@session.sql_bin_log within a
transaction what may lead to not correctly logging a transaction.
      
To fix the problems,  we created a thd->variables variable to represent
the "sql_log_bin" and prohibited its update inside a transaction or
sub-statement.

mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
  Updated result file. The reason the warnings are removed is
  related to BUG#50312.
mysql-test/suite/binlog/r/binlog_switch_inside_trans.result:
  Checks when is possible to change the option @@session.sql_log_bin.
mysql-test/suite/binlog/t/binlog_switch_inside_trans.test:
  Checks when is possible to change the option @@session.sql_log_bin.
mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result:
  Updated the result file with warnings that were being printed
  due to the wrong use of the thd->variables.option_bits and
  sql_log_bin_top_level variables.
mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result:
  Updated the result file with warnings that were being printed
  due to the wrong use of the thd->variables.option_bits and
  sql_log_bin_top_level variables.
sql/share/errmsg-utf8.txt:
  Introduces two error messages to notify that the @@session.sql_log_bin
  cannot be changed inside a sub-statement or transaction.
sql/sql_base.cc:
  Removes the variable sql_log_bin_toplevel and uses
  the session variable sql_log_bin.
sql/sql_class.cc:
  Replaces the variable sql_log_bin_toplevel by the
  (variables.option_bits & OPTION_BIN_LOG).
sql/sql_class.h:
  Removes the variable sql_log_bin_toplevel and creates 
  a session variable sql_log_bin.
sql/sys_vars.cc:
  Checks when the sql_log_bin can be correctly updated.

Also moved HA_DATA_PARTITION from ha_partition.cc to table.h.

to crash) from mysql-6.0-codebase.

The thing is that on some platforms (e.g. Mac OS X) sockaddr_in / sockaddr_in6
contain a non-standard field (sin_len / sin6_len), that must be set.

The problem was that only standard fields were set, thus getnameinfo() returned
EAI_SYSTEM instead of EAI_NONAME.

The fix is to introduce configure-time checks (for GNU auto-tools and CMake) for
those additional fields and to set them if they are available.

FOR UPDATE is causing a lock".
 
This patch tries to address problems which were exposed 
during backporting of original patch to 5.1 tree.
 
- It ensures that we don't change locking behavior of simple
  SELECT statements on InnoDB tables when they are executed
  under LOCK TABLES ... READ and with @@innodb_table_locks=0.
  Also we no longer pass TL_READ_DEFAULT/TL_WRITE_DEFAULT 
  lock types, which are supposed to be parser-only, to 
  handler::start_stmt() method.
- It makes check_/no_concurrent_insert.inc auxiliary scripts 
  more robust against changes in test cases that use them
  and also ensures that they don't unnecessarily change 
  environment of caller.

mysql-test/include/check_concurrent_insert.inc:
  Reset DEBUG_SYNC facility before and after using it in
  auxiliary script. This makes this script more robust against
  changes in test cases calling it. It also ensures that script
  does not unnecessarily change environment of caller.
mysql-test/include/check_no_concurrent_insert.inc:
  Reset DEBUG_SYNC facility before and after using it in
  auxiliary script. This makes this script more robust against
  changes in test cases calling it. It also ensures that script
  does not unnecessarily change environment of caller.
mysql-test/r/innodb-lock.result:
  Added coverage for LOCK TABLES ... READ behavior in
  @@innodb_table_locks = 0 mode. This test also checks
  that an appropriate type of lock is passed to
  handler::start_stmt() method.
mysql-test/t/innodb-lock.test:
  Added coverage for LOCK TABLES ... READ behavior in
  @@innodb_table_locks = 0 mode. This test also checks
  that an appropriate type of lock is passed to
  handler::start_stmt() method.
sql/sql_base.cc:
  Since we no longer set TL_READ as lock type for tables used  
  in simple SELECT right in the parser, in order to preserve  
  behavior for such statements on InnoDB tables when in  
  LOCK TABLES mode with @innodb_table_locks = 0,  
  check_lock_and_start_stmt() had to be changed to convert  
  TL_READ_DEFAULT to an appropriate type of read lock before  
  passing it to handler::start_stmt() method.  
  We do similar thing for TL_WRITE_DEFAULT as this lock type  
  is also supposed to be parser-only type.  
  As consequence read_lock_type_for_table() had to be  
  adjusted to behave properly when it is called from  
  check_lock_and_start_stmt() in prelocked mode.

(make relies GNU extentions). The patch was partially
backport from 6.0.

Original comment:
bug#30708: make relies GNU extensions.  Now that we no longer use
BitKeeper we can safely remove the SCCS handling with no loss of
functionality.

from 6.0 to trunk-bugfixing.

The problem was that OPTMIZE TABLE was allowed to run on a table
in use by a transaction in a different connection. This caused
repeatable read to break.

This bug was fixed by the introduction of metadata locking, WL#4284.
OPTIMIZE TABLE will now be blocked until the transaction using the
table, has ended.

This patch contains a regression test added to innodb_mysql_lock.test
and no code changes.

That was a pure test issue -- filter implementation in Perl did not work
on some platform (the bug occurred on Windows Server 2008 with
Cygwin Perl 5.10.0).

in a multiquery packet): fix NDB test failures.

removing disabled line for rpl_row_create_table  due to Bug#45576. Anyway, the test is still there because of Bug#51574

pushing to next-mr-bugfixing from working branch

multiquery packet).

Background:

  - a query can contain multiple SQL statements;

  - the server frees resources allocated to process a query when the
    whole query is handled. In other words, resources allocated to process
    one SQL statement from a multi-statement query are freed when all SQL
    statements are handled.

The problem was that the parser allocated a buffer of size of the whole
query for each SQL statement in a multi-statement query. Thus, if a query
had many SQL-statements (so, the query was long), but each SQL statement
was short, ther parser tried to allocate huge amount of memory (number of
small SQL statements * length of the whole query).

The memory was allocated for a so-called "cpp buffer", which is intended to
store pre-processed SQL statement -- SQL text without version specific
comments.

The fix is to allocate memory for the "cpp buffer" once for all SQL
statements (once for a query).

approved):

3161 Vladislav Vaintroub       2010-04-29                 
 Bug#53196 : CMake builds don't support 'make tags' and 
'make ctags' targets.  
   - Added tags and ctags targets


CMakeLists.txt:
  Add tags and ctags targets.
cmake/Makefile.am:
  Add a cmake file to build tags.
cmake/tags.cmake:
  Build tags and ctags.

for ALTER TABLE, LOAD DATA).

ROW_COUNT is now assigned according to the following rules:

  - In my_ok():
    - for DML statements: to the number of affected rows;
    - for DDL statements: to 0.

  - In my_eof(): to -1 to indicate that there was a result set.

    We derive this semantics from the JDBC specification, where int
    java.sql.Statement.getUpdateCount() is defined to (sic) "return the
    current result as an update count; if the result is a ResultSet
    object or there are no more results, -1 is returned".

  - In my_error(): to -1 to be compatible with the MySQL C API and
    MySQL ODBC driver.

  - For SIGNAL statements: to 0 per WL#2110 specification. Zero is used
    since that's the "default" value of ROW_COUNT in the diagnostics area.

sql/protocol.cc:
  Fix a typo.
sql/sql_class.h:
  - Introduce THD::get_row_count_func() / THD::set_row_count_func();
  - Remove the CF_HAS_ROW_COUNT define
sql/sql_parse.cc:
  CF_HAS_ROW_COUNT was eliminated.

type, which some time ago became part of Open_table_context class.
Apparently standalone enum type was erroneously re-introduced
during one of merges.

which was introduced by fix for bug 47459 "Assertion in
Diagnostics_area::set_eof_status on OPTIMIZE TABLE.

 - Update/fix file layouts for each package type, add new types for
   native package formats including deb, rpm and svr4.

 - Build all plugins, including debug versions

 - Update compiler flags to match current release

 - Add missing @VAR@ expansions

 - Install correct mysqclient library symlinks

 - Fix icc/ia64 builds

 - Fix install of libmysqld-debug

 - Don't include mysql_embedded

 - Remove unpackaged manual pages to avoid missing files warnings

 - Don't install mtr's test suite

with other merges from the old distribution-specific spec file.

 - update copyright notices

 - remove __os_install_post override, it was only necessary as a
   hack to build debuginfo packages - now that we no longer make
   them we can revert to the distribution macro which likely has
   other useful bits we might want

 - remove _unpackaged_files_terminate_build override, we want to
   know of any orphaned files

 - include native distribution support

 - no longer build separate debuginfo RPMs, instead just include
   debug/symbols in all binaries, which is more useful for support

 - include support for building commercial RPMs, requires a
   commercial source tree

 - remove cluster RPM support, we don't build them from this
   source tree

 - use CMake for building, and update package lists to match the
   new install layout/files.  Remove any options which were only
   useful for automake builds (e.g. yassl/zlib).

 - other minor cleanups

            via mysqld_safe

Plugin dir was set to a hard-coded path instead of relative the base dir.

This patch fixes this by using a path relative the basedir instead of the
plugin directory indicated by the configuration.