But Should Be "Zero Rows"


After applying the innodb snapshot 5.0-ss5406 for bug#40565, the windows push build
tests failed because of the missing cast of void * pointer in row0sel.c file

Informed the innodb developers and received patch by email.

Some collations--including cp1250_czech_cs,latin2_czech_cs,
ucs2/utf8_czech_ci, ucs2/utf8_danish_ci--are not being
sorted correctly by the IBMDB2I storage engine. This
was being caused because the sort order used by DB2 is
incompatible with the order expected by MySQL.

This patch removes support for the cp1250_czech_cs and
latin2_czech_cs collations because it has been determined
that the sort order used by DB2 is incompatible with the
order expected by MySQL. Users needing a czech collation
with IBMDB2I are encouraged to use a Unicode-based collation 
instead of these single-byte collations. This patch also
modifies the DB2 sort sequence used for ucs2/utf8_czech_ci
and ucs2/utf8_danish_ci collations to better match the
sorting expected by MySQL. This will only affect indexes
or tables that are newly created through the IBMDB2I storage
engine. Existing IBMDB2I tables will retain the old sort
sequence until recreated.

           format." warnings
      
Despite the fact that a statement would be filtered out from binlog, a
warning would still be thrown if it was issued with the LIMIT.
      
This patch addresses this issue by checking the filtering rules before
printing out the warning.

The TABLE::reginfo.impossible_range is used by the optimizer to indicate
that the condition applied to the table is impossible. It wasn't initialized
at table opening and this might lead to an empty result on complex queries:
a query might set the impossible_range flag on a table and when the query finishes,
all tables are returned back to the table cache. The next query that uses the table
with the impossible_range flag set and an index over the table will see the flag
and thus return an empty result.

The open_table function now initializes the TABLE::reginfo.impossible_range
variable.

such as quit and shutdown

Logging to slow log can produce an undetermined value for
Rows_examined in special cases. In debug mode this manifests
itself as any of the various marker values used to mark
uninitialized memory on various platforms.

If logging happens on a THD object that hasn't performed any
row reads (on this or any previous connections), the
THD::examined_row_count may be uninitialized. This patch adds
initialization for this attribute.

No automated test cases are added, as for this to be
meaningful, we need to ensure that we're using a THD
fulfilling the above conditions. This is hard to do in the
mysql-test-run framework. The patch has been verified
manually, however, by restarting mysqld and running the test
included with the bug report.

The problem is that the one phase commit function failed to
properly end a empty transaction. The solution is to ensure
that the transaction cleanup procedure is invoked even for
empty transactions.

The test case added failed sporadically on PB. This is due to the
fact that the user thread in some cases is waiting for slave IO
to stop and then check the error number. Thence, sometimes the
user thread would race for the error number with IO thread.

This post push fix addresses this by replacing the wait for slave
io to stop with a wait for slave io error (as it seems it was
added in 6.0 also after patch on which this is based was
pushed). This implied backporting wait_for_slave_io_error.inc
from 6.0 also.

Because of a regression introduced by bug#19027 the option --enable-foobar
doesn't work anymore for any plugin 'foobar'. The reason is that plugin
names are tristate options variables with optional parameters and integer
values are not accepted. Since the 'enable' prefix attempts to assign '1'
to the option the operation fails.

This patch translates any number n assigned to a plugin variable of type ENUM
to be the corresponding enumerated item. As a side effect --enable-foobar and
--disable-foobar will also start working again.

Added privilege checking to SHOW CREATE TRIGGER code.

BUG#40565 - Update Query Results in "1 Row Affected" But Should Be "Zero Rows"

Detailed revision comments:

r5232 | marko | 2009-06-03 14:31:04 +0300 (Wed, 03 Jun 2009) | 21 lines
branches/5.0: Merge r3590 from branches/5.1 in order to fix Bug #40565
(Update Query Results in "1 Row Affected" But Should Be "Zero Rows").

Also, add a test case for Bug #40565.

rb://128 approved by Heikki Tuuri
  ------------------------------------------------------------------------
  r3590 | marko | 2008-12-18 15:33:36 +0200 (Thu, 18 Dec 2008) | 11 lines

  branches/5.1: When converting a record to MySQL format, copy the default
  column values for columns that are SQL NULL.  This addresses failures in
  row-based replication (Bug #39648).

  row_prebuilt_t: Add default_rec, for the default values of the columns in
  MySQL format.

  row_sel_store_mysql_rec(): Use prebuilt->default_rec instead of
  padding columns.

  rb://64 approved by Heikki Tuuri
  ------------------------------------------------------------------------

BUG#38479 - valgrind warnings in show table status for innodb tables

Detailed revision comments:

r5080 | vasil | 2009-05-22 14:45:34 +0300 (Fri, 22 May 2009) | 6 lines
branches/5.0:

Fix Bug#38479 valgrind warnings in show table status for innodb tables

by initializing prebuilt->hint_need_to_fetch_extra_cols.

In Item_param::set_from_user_var
value.cs_info.character_set_client is set
to 'fromcs' value. It's wrong, it should be set to
thd->variables.character_set_client.

            
The reason for the crash was rotate_relay_log (mi=0x0) did not verify
the passed value of active_mi.  There are more cases where active_mi
is supposed to be non-zero e.g change_master(), stop_slave(), and it's
reasonable to protect from a similar crash all of them with common
fixes.
            
Fixed with spliting end_slave() in slave threads release and slave
data clean-up parts (a new close_active_mi()). The new function is
invoked at the very end of close_connections() so that all users of
active_mi are proven to have left.

            queries if query was killed 
 
Since we rely on thd->is_error() to decide whether we should 
COMMIT or ROLLBACK after a query execution, check the query 
'killed' state and throw an error before calling 
ha_autocommit_or_rollback(), not after. 
 
The patch was tested manually. For reliable results, the test 
case would have to KILL QUERY while a DELETE/UPDATE query in 
another thread is still running. I don't see a way to achieve 
this kind of synchronization in our test suite (no debug_sync 
in 5.1).

Bug#44653: Server crash noticed when executing random queries with partitions.

When opening a table, it is imperative that the flag
TABLE::auto_increment_field_not_null be false. But if an error occured during
the creation of a table (e.g. the table exists already) with an auto_increment
column and a BEFORE trigger that used the INSERT ... SELECT construct, the
flag was not reset until after error checking. Thus if an error occured,
select_insert::send_data() returned immediately and it was not reset (see * in
pseudocode below).  Crash happened if the table was opened again. Fixed by
resetting the flag after error checking.

nested-loops_join():
  for each row in SELECT table {
    select_insert::send_data():
      if a values is supplied for AUTO_INCREMENT column
         table->auto_increment_field_not_null= TRUE
       else
         table->auto_increment_field_not_null= FALSE
       if (error)
         return 1; *
       if (table->auto_increment_field_not_null == FALSE)
         ...
       table->auto_increment_field_not_null == FALSE 
  }
<-- table returned to table cache and later retrieved by open_table: 
open_table():
  assert(table->auto_increment_field_not_null)

A hardcoded use of nm and libc was put into configure.in. This broke
cross-compiling and is bad practice. Fitting variables now used.