with binlog_format = MIXED or ROW.

NOTE: This undoes changes by BUG#42829 in sql_class.cc:binlog_query().
I will revert the change in a post-push fix (the binlog filter should
be checked in sql_base.cc:decide_logging_format()).

General overview:
The logic for switching to row format when binlog_format=MIXED had
numerous flaws. The underlying problem was the lack of a consistent
architecture.
General purpose of this changeset:
This changeset introduces an architecture for switching to row format
when binlog_format=MIXED. It enforces the architecture where it has
to. It leaves some bugs to be fixed later. It adds extensive tests to
verify that unsafe statements work as expected and that appropriate
errors are produced by problems with the selection of binlog format.
It was not practical to split this into smaller pieces of work.

Problem 1:
To determine the logging mode, the code has to take several parameters
into account (namely: (1) the value of binlog_format; (2) the
capabilities of the engines; (3) the type of the current statement:
normal, unsafe, or row injection). These parameters may conflict in
several ways, namely:
 - binlog_format=STATEMENT for a row injection
 - binlog_format=STATEMENT for an unsafe statement
 - binlog_format=STATEMENT for an engine only supporting row logging
 - binlog_format=ROW for an engine only supporting statement logging
 - statement is unsafe and engine does not support row logging
 - row injection in a table that does not support statement logging
 - statement modifies one table that does not support row logging and
   one that does not support statement logging
Several of these conflicts were not detected, or were detected with
an inappropriate error message. The problem of BUG#39934 was that no
appropriate error message was written for the case when an engine
only supporting row logging executed a row injection with
binlog_format=ROW. However, all above cases must be handled.
Fix 1:
Introduce new error codes (sql/share/errmsg.txt). Ensure that all
conditions are detected and handled in decide_logging_format()

Problem 2:
The binlog format shall be determined once per statement, in
decide_logging_format(). It shall not be changed before or after that.
Before decide_logging_format() is called, all information necessary to
determine the logging format must be available. This principle ensures
that all unsafe statements are handled in a consistent way.
However, this principle is not followed:
thd->set_current_stmt_binlog_row_based_if_mixed() is called in several
places, including from code executing UPDATE..LIMIT,
INSERT..SELECT..LIMIT, DELETE..LIMIT, INSERT DELAYED, and
SET @@binlog_format. After Problem 1 was fixed, that caused
inconsistencies where these unsafe statements would not print the
appropriate warnings or errors for some of the conflicts.
Fix 2:
Remove calls to THD::set_current_stmt_binlog_row_based_if_mixed() from
code executed after decide_logging_format(). Compensate by calling the
set_current_stmt_unsafe() at parse time. This way, all unsafe statements
are detected by decide_logging_format().

Problem 3:
INSERT DELAYED is not unsafe: it is logged in statement format even if
binlog_format=MIXED, and no warning is printed even if
binlog_format=STATEMENT. This is BUG#45825.
Fix 3:
Made INSERT DELAYED set itself to unsafe at parse time. This allows
decide_logging_format() to detect that a warning should be printed or
the binlog_format changed.

Problem 4:
LIMIT clause were not marked as unsafe when executed inside stored
functions/triggers/views/prepared statements. This is
BUG#45785.
Fix 4:
Make statements containing the LIMIT clause marked as unsafe at
parse time, instead of at execution time. This allows propagating
unsafe-ness to the view.

without error

When using quick access methods for searching rows in UPDATE or 
DELETE there was no check if a fatal error was not already sent 
to the client while evaluating the quick condition.
As a result a false OK (following the error) was sent to the 
client and the error was thus transformed into a warning.

Fixed by checking for errors sent to the client during 
SQL_SELECT::check_quick() and treating them as real errors.

Fixed a wrong test case in group_min_max.test
Fixed a wrong return code in mysql_update() and mysql_delete()

            mutually-nested subqueries

Queries of the form

  SELECT * FROM (SELECT 1) AS t1,
                (SELECT 2) AS t2,...
                (SELECT 32) AS t32

caused the "Too high level of nesting for select" error
as if the query has a form

  SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM...


The table_factor parser rule has been modified to adjust
the LEX::nest_level variable value after every derived table.

Remove commented-out test case. It has been moved to innodb_bug21704.test

  sort_buffer_size cannot allocate

The NULL return from tree_insert() (on low memory) was not
checked for in Item_func_group_concat::add(). As a result
on low memory conditions a crash happens.

Fixed by properly checking the return code.

1. BUG#21704 - Renaming column does not update FK definition

2. Changes in mysql-test/include/mtr_warnings.sql so that the testcase
   for BUG#21704 doesn't fail because of the warnings generated.

Detailed revision comments:

r5488 | vasil | 2009-07-09 19:16:44 +0300 (Thu, 09 Jul 2009) | 13 lines
branches/5.1:

Fix Bug#21704 Renaming column does not update FK definition

by checking whether a column that participates in a FK definition is being
renamed and denying the ALTER in this case.

The patch was originally developed by Davi Arnaut <Davi.Arnaut@Sun.COM>:
http://lists.mysql.com/commits/77714
and was later adjusted to conform to InnoDB coding style by me (Vasil),
I also added some more comments and moved the bug specific mysql-test to
a separate file to make it more manageable and flexible.

            and base tables 

myrg_attach_children() could reuse a buffer that was allocated 
previously based on a definition of a child table. The problem 
was that the child's definition might have been changed, so 
reusing the buffer could lead to crashes or valgrind errors 
under some circumstances. 
 
Fixed by changing myrg_attach_children() so that the 
rec_per_key_part buffer is reused only when the child table
have not changed, and reallocated otherwise (the old buffer is 
deallocated if necessary).

Detailed revision comments:

r5440 | vasil | 2009-06-30 13:04:29 +0300 (Tue, 30 Jun 2009) | 8 lines
branches/5.1:

Fix Bug#45814 URL reference in InnoDB server errors needs adjusting to match documentation

by changing the URL from
http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting.html to
http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting-datadict.html

BUG#45749 - Race condition in SET GLOBAL innodb_commit_concurrency=DEFAULT

Detailed revision comments:

r5419 | marko | 2009-06-25 16:11:57 +0300 (Thu, 25 Jun 2009) | 18 lines
branches/5.1: Merge r5418 from branches/zip:

  ------------------------------------------------------------------------
  r5418 | marko | 2009-06-25 15:55:52 +0300 (Thu, 25 Jun 2009) | 5 lines
  Changed paths:
     M /branches/zip/ChangeLog
     M /branches/zip/handler/ha_innodb.cc
     M /branches/zip/mysql-test/innodb_bug42101-nonzero.result
     M /branches/zip/mysql-test/innodb_bug42101-nonzero.test
     M /branches/zip/mysql-test/innodb_bug42101.result
     M /branches/zip/mysql-test/innodb_bug42101.test
  
  branches/zip: Fix a race condition caused by
  SET GLOBAL innodb_commit_concurrency=DEFAULT. (Bug #45749)
  When innodb_commit_concurrency is initially set nonzero,
  DEFAULT would change it back to 0, triggering Bug #42101.
  rb://139 approved by Heikki Tuuri.
  ------------------------------------------------------------------------

1. Fixes build warnings caused by applying snapshot 5.1-ss5282

2. Fix the Makefile.am in storage/innobase to remove the header file
   'fsp0types.h' which was added twice to fix build warning generated 
   after applying the 5.1-ss5282 snapshot

Detailed revision comments:

r5410 | marko | 2009-06-24 22:26:34 +0300 (Wed, 24 Jun 2009) | 2 lines
branches/5.1: Add missing #include "mtr0log.h" to avoid warnings
when compiling with -DUNIV_MUST_NOT_INLINE.

unnecessarily
      
The problem is that libmysqlclient.so is built with THREAD
undefined, while a client compiling against the same header
files will see THREAD as defined and definitions in
my_pthread.h will be included, possibly resulting in undefined
symbols that cannot be resolved with libmysqlclient.so.
      
The suggested solution is to require that clients wanting to
link with libmysqlclient.so should be built with
MYSQL_CLIENT_NO_THREADS defined. This requires a documentation
change, and more details for this will be supplied if this
patch is approved.
      
The MYSQL_CLIENT_NO_THREADS define was renamed from
UNDEF_THREADS_HACK, to get a more suitable (less suspicious)
name for the define. (The UNDEF_THREADS_HACK is retained for
backwards compatibility, though.)
      
This patch is also in anticipation of WL#4958, which will
remove this problem altogether by dropping the building of
libmysqlclient.

Item_field::fix_fields()