BUG#46364 introduced the flag binlog_direct_non_transactional_updates which
would make N-changes to be written to the binary log upon committing the
statement when "ON". On the other hand, when "OFF" the option was supposed
to mimic the behavior in 5.1. However, the implementation was not mimicking
the behavior correctly and the following bugs popped up:

  Case #1: N-changes executed within a transaction would go into
           the S-cache. When later in the same transaction a
           T-change occurs, N-changes following it were written
           to the T-cache instead of the S-cache. In some cases,
           this raises problems. For example, a
           Table_map_log_event being written initially into the
           S-cache, together with the initial N-changes, would be
           absent from the T-cache. This would log N-changes
           orphaned from a Table_map_log_event (thence discarded
           at the slave). (MIXED and ROW)

   Case #2: When rolling back a transaction, the N-changes that
            might be in the T-cache were disregarded and
            truncated along with the T-changes. (MIXED and ROW)

   Case #3: When a MIXED statement (TN) is ahead of any other
            T-changes in the transaction and it fails, it is kept
            in the T-cache until the transaction ends. This is
            not the case in 5.1 or Betony (5.5.2). In these, the
            failed TN statement would be written to the binlog at
            the same instant it had failed and not deferred until
            transaction end. (SBR)

To fix these problems, we have decided to do what follows:

   For Case #1 and #2, we circumvent them:

      1. by not letting binlog_direct_non_transactional_updates
         affect MIXED and RBR. These modes will keep the behavior
         provided by WL#2687. Although this will make Celosia to
         behave differently from 5.1, an execution will be always
         safe under such modes in the sense that slaves will never
         go out sync. In 5.1, using either MIXED or ROW while
         mixing N-statements and T-statements was not safe.

   For Case #3, we don't actually fix it. We:

      1. keep it and make all MIXED statements whether they end
         up failing or not or whether they are up front in the
         transaction or after some transactional change to always
         be stored in the T-cache. This means that it is written
         to the binary log on transaction commit/rollback only.

      2. We make the warning message even more specific about the
         MIXED statement and SBR.

Reading from a self-logging engine and updating a transactional engine such as Innodb
generates changes that are written to the binary log in the statement format and may
make slaves diverge. In the mixed mode, such changes should be written to the binary
log in the row format.

Note that the issue does not happen if we mix a self-logging engine and MyIsam
as this case is caught by checking the mixture of non-transactional and transactional
engines.

So, we classify a mixed statement where one reads from NDB and writes into another 
engine as unsafe:

if (multi_engine && flags_some_set & HA_HAS_OWN_BINLOGGING)
  lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_MULTIPLE_ENGINES_AND_SELF_LOGGING_ENGINE);

The task is to 
  (a) add a comment on indexes and 
  (b) increase the maximum length of column, table and the new index comments.

The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).

Removed --remove_file in cleanup procedure

WL#5154 - Remove deprecated 4.1 features

The fix is the removal of the sql_log_update_basic
test, as this option is deprecated and removed,
and a minor change to the result file of
lc_time_names_basic as the error message has
changed.

This is a post-fix cleanup to move rpl.rpl_timezone out
of 'experimental' state.

 - Changes to the banner text
 - Use older AC_PROG_LIBTOOL (Bug#51009)

scripts/mysql_install_db.sh
 - Changes to banner text

Added --max-connections= argument to mysqltest and mtr
Small fix to first patch: forgot to check before free'ing connections array

in 'kostja@sun.com-20091210084103-l4f8u62u4evoy3dc'.

This file is necessary for Windows builds.

Some logic would group by suite always
Disable this if using --noreorder
Also fix getting array from collect_one_suite() in this case
Amended according to previous comment

    Multi_polygon::centroid() has an error in the implementation
      
per-file messages:
  sql/spatial.cc
Bug#38959      archive_gis fails due to rounding difference
        multi_polygon::centroid() implementation fixed

Replaced --default-character-set with --character-set-server
Replaced --language with --lc-messages-dir
NB full test suite not tested yet

WL#5154 was a task for formally deprecating and removing items that
were mentioned in the manual as having been deprecated since MySQL
4.1 or 5.0, but that had never been removed.

Since WL#5154 was created, examination of mysqld.cc, mysql.cc, and
mysqldump.c reveals additional deprecations not mentioned in the
manual. (In some cases, the items are simply not mentioned in the
5.1+ manuals.)

This is a follow-on task to deprecate and remove these additional
items.

The deprecation happened in MySQL 5.1, and the options/variables
are now removed from the code.

A set of program options and variables was deprecated in
MySQL 5.1, and is hereby removed.

Merge mysql-trunk-bugfixing -> mysql-next-mr-bugfixing

1. Now test use fake_relay_log primitive
2. Added RESET SLAVE to include/setup_fake_relay_log.inc for removing relay log info file
3. Added RESET SLAVE to include/cleanup_fake_relay_log.inc
4. Test moved to rpl suite as rpl_binlog_auto_inc_bug33029.test
5. Updated result file

Compilation failure problems on non-i386 platforms.
Adding missing parenthesis.