Change the warning message to 'Statement may not be safe to log in
statement format' to indicate that the decision on whether a
statement is safe or not is heuristic, and we are conservative.

  and HAVING

When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the 
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type 
calculation for IN but before the run-time type calculations, 
it causes the type calculations in the IN function done at run time 
to get unexpected results different from what was prepared at compile time.

In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the matrix
at compile time, so if any of the arguments of the CASE function changes 
its type to a string it will still be covered by the information prepared 
at compile time.
Extended the CASE fix for cover the IN case.
An alternative way of fixing this problem is by caching the result type of 
the arguments at compile time and using the cached information at run time
instead of re-calculating the result types.
Preferred the CASE approach for uniformity and fix localization.

BUG#42101 - Race condition in innodb_commit_concurrency

Detailed revision comments:

r4994 | marko | 2009-05-14 15:04:55 +0300 (Thu, 14 May 2009) | 18 lines
branches/5.1: Prevent a race condition in innobase_commit() by ensuring
that innodb_commit_concurrency>0 remains constant at run time. (Bug #42101)

srv_commit_concurrency: Make this a static variable in ha_innodb.cc.

innobase_commit_concurrency_validate(): Check that innodb_commit_concurrency
is not changed from or to 0 at run time.  This is needed, because
innobase_commit() assumes that innodb_commit_concurrency>0 remains constant.
Without this limitation, the checks for innodb_commit_concurrency>0
in innobase_commit() should be removed and that function would have to
acquire and release commit_cond_m at least twice per invocation.
Normally, innodb_commit_concurrency=0, and introducing the mutex operations
would mean significant overhead.

innodb_bug42101.test, innodb_bug42101-nonzero.test: Test cases.

rb://123 approved by Heikki Tuuri

BUG#44320 - InnoDB: missing DB_ROLL_PTR in Table Monitor COLUMNS output

Detailed revision comments:

r4976 | marko | 2009-05-13 15:44:54 +0300 (Wed, 13 May 2009) | 6 lines
branches/5.1: Display DB_ROLL_PTR in the COLUMNS section of the
innodb_table_monitor output.  It was accidentally omitted due to an
off-by-one loop condition.  (Bug #44320)

rb://116 approved by Heikki Tuuri

Detailed revision comments:

r4705 | vasil | 2009-04-14 14:30:13 +0300 (Tue, 14 Apr 2009) | 7 lines
branches/5.1:

When using the random function, first take the modulus by the number of pages
and then typecast to ulint.

This is a followup to r4699 - the fix of Bug#43660.

Internal InnoDN FK parser does not recognize '\'' as quotation symbol.
Suggested fix is to add '\'' symbol check for quotation condition
(dict_strip_comments() function).

Problem: executing queries like "ALTER TABLE view1;" we don't
check new view's name (which is not specified),
that leads to server crash.

Fix: do nothing (to be consistent with the behaviour for tables) 
in such cases.

           with a "HAVING" clause though query works

SELECT from views defined like:

  CREATE VIEW v1 (view_column)
    AS SELECT c AS alias FROM t1 HAVING alias

fails with an error 1356:
  View '...' references invalid table(s) or column(s)
  or function(s) or definer/invoker of view lack rights
  to use them


CREATE VIEW form with a (column list) substitutes
SELECT column names/aliases with names from a
view column list.
However, alias references in HAVING clause was
not substituted.


The Item_ref::print function has been modified
to write correct aliased names of underlying
items into VIEW definition generation/.frm file.

Disabling these two tests as they are affected by this bug / causing PB2 failures
on Windows platforms.  Can always disable via include/not_windows.inc if
the bug fix looks like it will take some time.

Fixed start up options for test case "rpl_ndb_2other-slave" to match
the changed behavior for plugin options.

convert_dash_to_underscore was supplied with a character length containing
my byte too many which caused valgrind errors of invalid read.

The RAND(N) function where the N is a field of "constant" table
(table of single row) failed with a SIGFPE.

Evaluation of RAND(N) rely on constant status of its argument.
Current server "seeded" random value for each constant argument
only once, in the Item_func_rand::fix_fields method.
Then the server skipped a call to seed_random() in the
Item_func_rand::val_real method for such constant arguments.

However, non-constant state of an argument may be changed
after the call to fix_fields, if an argument is a field of
"constant" table. Thus, pre-initialization of random value
in the fix_fields method is too early.


Initialization of random value by seed_random() has been
removed from Item_func_rand::fix_fields method.
The Item_func_rand::val_real method has been modified to
call seed_random() on the first evaluation of this method
if an argument is a function.

Fix bug in mtr_cases.pm script visible only when InnoDB isn't configured.

Occasionally, if both the partition_pruning
and partition_range tests are run sequentially
against the IBMDB2I engine, the partition_range
test will fail.

Compiler padding on a 64-bit build allowed
garbage data in the hash key used for
caching open iconv descriptors. As a
result, cached descriptors were not found,
and multiple duplicate iconv descriptors
were opened for a single character set.
Eventually, the maximum number of open
iconv descriptors was reached, and further
iconv_open() calls would fail, leading the
storage engine to report incorrectly that
the character set was not supported.

This patch widens the 16-bit members of the
hash key to 32 bits to eliminate compiler
padding. The entire length of the hash key
is now initialized correctly on both 32-bit
and 64-bit builds.

In order to better support the usage of
IBMDB2I tables from within RPG programs,
the storage engine should ensure that the
RCDFMT name is consistent and predictable
for DB2 tables.

This patch appends a "RCDFMT <name>"
clause to the CREATE TABLE statement
that is passed to DB2.  <name> is
generated from the original name of
the table itself. This ensures a
consistent and deterministic mapping
from the original table.

For the sake of simplicity only
the alpha-numeric characters are
preserved when generating the new
name, and these are upper-cased;
other characters are replaced with
an underscore (_). Following DB2
system identifier rules, the name
always begins with an alpha-character
and has a maximum of ten characters.
If no usable characters are found in
the table name, the name X is used.

  It turns out that this test case no longer fails with the discrepancy
  in numbers that was the original cause for disabling this test (and showed
  potential genuine issues with the query cache). Therefore
  this test is being enabled after some minor adjustment of error codes and
  messages.

Details:
1. Add missing "disconnect <session>"
2. Take care that the disconnects are finished when the test terminates
3. Replace error names by error numbers
4. Minor beautifying of script code

 
Field_time::get_time() did not initialize some members of 
MYSQL_TIME which led to valgrind warnings when those members 
were accessed in Protocol_simple::store_time(). 
 
It is unlikely that this bug could result in wrong data 
being returned, since Field_time::get_time() initializes the 
'day' member of MYSQL_TIME to 0, so the value of 'day' 
in Protocol_simple::store_time() would be 0 regardless 
of the values for 'year' and 'month'.