bzr push into mysql-5.1-bugteam branch (luis.soares:2982 to 2983)

[Luis Soares]

 2983 Luis Soares	2009-06-29 [merge]
      merge: 5.1-bt bug branch --> 5.1-bt latest

    added:
      mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result
      mysql-test/suite/binlog/t/binlog_stm_unsafe_warning-master.opt
      mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test
    modified:
      sql/sql_class.cc
 2982 V Narayanan	2009-06-29
      Bug#45196  Some collations do not sort correctly with IBMDB2I
      
      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.
     @ mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45196.result
        Bug#45196  Some collations do not sort correctly with IBMDB2I
        
        Result file for the test case.
     @ mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45196.test
        Bug#45196  Some collations do not sort correctly with IBMDB2I
        
        Adding tests for testing the sort order with the modified collations.
     @ storage/ibmdb2i/db2i_collationSupport.cc
        Bug#45196  Some collations do not sort correctly with IBMDB2I
        
        Remove the 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.

    added:
      mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45196.result
      mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45196.test
    modified:
      storage/ibmdb2i/db2i_collationSupport.cc
=== added file 'mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result'
--- a/mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result	1970-01-01 00:00:00 +0000
+++ b/mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result	2009-06-27 13:18:47 +0000
@@ -0,0 +1,30 @@
+### NOT filtered database => assertion: warnings ARE shown
+DROP TABLE IF EXISTS t1;
+CREATE TABLE t1 (a int, b int, primary key (a));
+INSERT INTO t1 VALUES (1,2), (2,3);
+UPDATE t1 SET b='4' WHERE a=1 LIMIT 1;
+Warnings:
+Note	1592	Statement may not be safe to log in statement format.
+UPDATE t1 SET b='5' WHERE a=2 ORDER BY a LIMIT 1;
+Warnings:
+Note	1592	Statement may not be safe to log in statement format.
+DROP TABLE t1;
+### NOT filtered database => assertion: binlog disabled and warnings ARE NOT shown
+SET SQL_LOG_BIN= 0;
+DROP TABLE IF EXISTS t1;
+CREATE TABLE t1 (a int, b int, primary key (a));
+INSERT INTO t1 VALUES (1,2), (2,3);
+UPDATE t1 SET b='4' WHERE a=1 LIMIT 1;
+UPDATE t1 SET b='5' WHERE a=2 ORDER BY a LIMIT 1;
+DROP TABLE t1;
+SET SQL_LOG_BIN= 1;
+### FILTERED database => assertion: warnings ARE NOT shown
+CREATE DATABASE b42851;
+USE b42851;
+DROP TABLE IF EXISTS t1;
+CREATE TABLE t1 (a int, b int, primary key (a));
+INSERT INTO t1 VALUES (1,2), (2,3);
+UPDATE t1 SET b='4' WHERE a=1 LIMIT 1;
+UPDATE t1 SET b='5' WHERE a=2 ORDER BY a LIMIT 1;
+DROP TABLE t1;
+DROP DATABASE b42851;

=== added file 'mysql-test/suite/binlog/t/binlog_stm_unsafe_warning-master.opt'
--- a/mysql-test/suite/binlog/t/binlog_stm_unsafe_warning-master.opt	1970-01-01 00:00:00 +0000
+++ b/mysql-test/suite/binlog/t/binlog_stm_unsafe_warning-master.opt	2009-06-27 13:18:47 +0000
@@ -0,0 +1 @@
+--binlog-ignore-db=b42851

=== added file 'mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test'
--- a/mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test	1970-01-01 00:00:00 +0000
+++ b/mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test	2009-06-27 13:18:47 +0000
@@ -0,0 +1,73 @@
+# BUG#42851: Spurious "Statement is not safe to log in statement
+#            format." warnings
+#
+# WHY
+# ===
+#   
+#   This test aims at checking that the fix that removes spurious
+#   entries in the error log when the statement is filtered out from
+#   binlog, is working.
+#
+# HOW
+# ===
+#
+#   The test case is split into three assertions when issuing statements
+#   containing LIMIT and ORDER BY:
+#
+#     i) issue statements in database that is not filtered => check
+#        that warnings ARE shown;
+#
+#    ii) issue statements in database that is not filtered, but with
+#        binlog disabled => check that warnings ARE NOT shown;
+#
+#   iii) issue statements in database that is filtered => check that
+#        warnings ARE NOT shown.
+
+-- source include/have_log_bin.inc
+-- source include/have_binlog_format_statement.inc
+
+-- echo ### NOT filtered database => assertion: warnings ARE shown
+
+-- disable_warnings
+DROP TABLE IF EXISTS t1;
+-- enable_warnings
+
+CREATE TABLE t1 (a int, b int, primary key (a));
+INSERT INTO t1 VALUES (1,2), (2,3);
+UPDATE t1 SET b='4' WHERE a=1 LIMIT 1;
+UPDATE t1 SET b='5' WHERE a=2 ORDER BY a LIMIT 1;
+DROP TABLE t1;
+
+-- echo ### NOT filtered database => assertion: binlog disabled and warnings ARE NOT shown
+
+SET SQL_LOG_BIN= 0;
+
+-- disable_warnings
+DROP TABLE IF EXISTS t1;
+-- enable_warnings
+
+CREATE TABLE t1 (a int, b int, primary key (a));
+INSERT INTO t1 VALUES (1,2), (2,3);
+UPDATE t1 SET b='4' WHERE a=1 LIMIT 1;
+UPDATE t1 SET b='5' WHERE a=2 ORDER BY a LIMIT 1;
+DROP TABLE t1;
+
+SET SQL_LOG_BIN= 1;
+
+-- echo ### FILTERED database => assertion: warnings ARE NOT shown
+
+CREATE DATABASE b42851;
+USE b42851;
+
+-- disable_warnings
+DROP TABLE IF EXISTS t1;
+-- enable_warnings
+
+CREATE TABLE t1 (a int, b int, primary key (a));
+INSERT INTO t1 VALUES (1,2), (2,3);
+UPDATE t1 SET b='4' WHERE a=1 LIMIT 1;
+UPDATE t1 SET b='5' WHERE a=2 ORDER BY a LIMIT 1;
+DROP TABLE t1;
+
+# clean up
+DROP DATABASE b42851;

=== modified file 'sql/sql_class.cc'
--- a/sql/sql_class.cc	2009-06-25 15:41:05 +0000
+++ b/sql/sql_class.cc	2009-06-27 13:18:47 +0000
@@ -27,6 +27,7 @@
 
 #include "mysql_priv.h"
 #include "rpl_rli.h"
+#include "rpl_filter.h"
 #include "rpl_record.h"
 #include "slave.h"
 #include <my_bitmap.h>
@@ -3684,7 +3685,8 @@ int THD::binlog_query(THD::enum_binlog_q
     we should print a warning.
   */
   if (sql_log_bin_toplevel && lex->is_stmt_unsafe() &&
-      variables.binlog_format == BINLOG_FORMAT_STMT)
+      variables.binlog_format == BINLOG_FORMAT_STMT && 
+      binlog_filter->db_ok(this->db))
   {
    /*
      A warning can be elevated a error when STRICT sql mode.


Attachment: [text/bzr-bundle] bzr/[e-mail]