List:Commits« Previous MessageNext Message »
From:Marc Alff Date:March 1 2012 10:44am
Subject:bzr push into mysql-trunk branch (marc.alff:3709 to 3710)
View as plain text  
 3710 Marc Alff	2012-03-01
      Fixed robustness of tests hostcache_ipv4_max_con, hostcache_ipv6_max_con

    modified:
      mysql-test/suite/perfschema/r/hostcache_ipv4_max_con.result
      mysql-test/suite/perfschema/r/hostcache_ipv6_max_con.result
      mysql-test/suite/perfschema/t/hostcache_ipv4_max_con.test
      mysql-test/suite/perfschema/t/hostcache_ipv6_max_con.test
      sql/mysqld.cc
 3709 Jorgen Loland	2012-03-01
      BUG#11764155 - INCONSISTENT 'OUT OF RANGE' WARNING MESSAGE ON 
                     SELECT
      
      When the optimizer decides to use ref access on a table, the
      conditions that are guaranteed to be satisfied by the ref 
      access itself does not need to be checked in the server.
      
      Removal of such "guaranteed by ref access" conditions is done
      by make_cond_for_table_from_pred(). One way a predicate can be
      guaranteed to be satisfied is if the consition is on the
      form "field = constant" and the field is covered by the index.
      In addition, it is required that the constant can be converted 
      to the field's type without error when test_if_ref() saves the 
      const value in the field.
      
      Consider the following query where the constant is higher than
      the maximum int value:
      
      SELECT * FROM t1 WHERE int_col = 999999999999
      
      The problem in this bug was that the value was stored using
      thd->count_cuted_fields == CHECK_FIELD_WARN. Because of this,
      store_val_in_field() would emit a warning when the too-high
      integer in the above query was stored. There is no use for this
      warning. In fact, when the range optimizer does a similar thing
      when building the ranges, get_mm_leaf() calls
      Item::save_in_field_no_warnings() instead to turn off warnings. 
      
      The fix is a simplification: the function store_val_in_field() 
      is removed and replaced with Item::save_in_field_no_warnings().
      store_val_in_field() was used only to store constants in key
      fields and was almost identical to
      Item::save_in_field_no_warnings(). The difference between these
      functions was that 
        a) the latter did not give warnings (which is desirable), and
        b) the latter accepts storing a 0000-00-00 date even when 
           the SQL mode does not permit it. This is OK and even 
           desirable because store_val_in_field() was only called for
           queries. Before this change, a query of the form 
      
              "SELECT * FROM t1 WHERE date_col = '0000-00-00'" 
      
           that was ref-accessed through an index covering date_col, 
           would not only evaluate the condition by ref-accessing in
           the index but also in the server because 
           store_val_in_field() reported "hey! NULL dates are not 
           allowed".
     @ mysql-test/r/type_date.result
        Queries should not get an "out of range" warning when an
        out-of-range constant is specified.
        Explain changes for some queries with ref-access using
        0000-00-00 date constants as lookup value. The condition is 
        guaranteed to be true in this case.
     @ sql/opt_sum.cc
        Replace store_val_in_field() with 
        Item::save_in_field_no_warnings()
     @ sql/sql_optimizer.cc
        Replace store_val_in_field() with 
        Item::save_in_field_no_warnings()
     @ sql/sql_select.cc
        Remove store_val_in_field()
     @ sql/sql_select.h
        Remove store_val_in_field()

    modified:
      mysql-test/r/type_date.result
      sql/opt_sum.cc
      sql/sql_optimizer.cc
      sql/sql_select.cc
      sql/sql_select.h
=== modified file 'mysql-test/suite/perfschema/r/hostcache_ipv4_max_con.result'
--- a/mysql-test/suite/perfschema/r/hostcache_ipv4_max_con.result	2012-02-20 11:11:30 +0000
+++ b/mysql-test/suite/perfschema/r/hostcache_ipv4_max_con.result	2012-03-01 10:44:16 +0000
@@ -582,7 +582,7 @@ COUNT_LOCAL_ERRORS	0
 COUNT_UNKNOWN_ERRORS	0
 FIRST_ERROR_SEEN	set
 LAST_ERROR_SEEN	set
-ERROR 08004: Too many connections
+Got one of the listed errors
 "Dumping performance_schema.host_cache"
 IP	192.0.2.4
 HOST	santa.claus.ipv4.example.com
@@ -611,7 +611,7 @@ COUNT_LOCAL_ERRORS	0
 COUNT_UNKNOWN_ERRORS	0
 FIRST_ERROR_SEEN	set
 LAST_ERROR_SEEN	set
-ERROR 08004: Too many connections
+Got one of the listed errors
 "Dumping performance_schema.host_cache"
 IP	192.0.2.4
 HOST	santa.claus.ipv4.example.com

=== modified file 'mysql-test/suite/perfschema/r/hostcache_ipv6_max_con.result'
--- a/mysql-test/suite/perfschema/r/hostcache_ipv6_max_con.result	2012-02-20 11:11:30 +0000
+++ b/mysql-test/suite/perfschema/r/hostcache_ipv6_max_con.result	2012-03-01 10:44:16 +0000
@@ -582,7 +582,7 @@ COUNT_LOCAL_ERRORS	0
 COUNT_UNKNOWN_ERRORS	0
 FIRST_ERROR_SEEN	set
 LAST_ERROR_SEEN	set
-ERROR 08004: Too many connections
+Got one of the listed errors
 "Dumping performance_schema.host_cache"
 IP	2001:db8::6:6
 HOST	santa.claus.ipv6.example.com
@@ -611,7 +611,7 @@ COUNT_LOCAL_ERRORS	0
 COUNT_UNKNOWN_ERRORS	0
 FIRST_ERROR_SEEN	set
 LAST_ERROR_SEEN	set
-ERROR 08004: Too many connections
+Got one of the listed errors
 "Dumping performance_schema.host_cache"
 IP	2001:db8::6:6
 HOST	santa.claus.ipv6.example.com

=== modified file 'mysql-test/suite/perfschema/t/hostcache_ipv4_max_con.test'
--- a/mysql-test/suite/perfschema/t/hostcache_ipv4_max_con.test	2012-02-06 09:13:43 +0000
+++ b/mysql-test/suite/perfschema/t/hostcache_ipv4_max_con.test	2012-03-01 10:44:16 +0000
@@ -197,8 +197,30 @@ select current_user();
 --connection default
 --source ../include/hostcache_dump.inc
 
+# About error ER_CON_COUNT_ERROR:
+# - this error is associated with SQLSTATE 08004,
+#   and returned from 2 places in the server code.
+# - which path returns the error is not predictable,
+#   as it depends on the server load and thread scheduling
+# - one path returns a SQLSTATE of 08004
+# - another path returns no SQLSTATE at all,
+#   and then the client sets a default value of HY000 for SQLSTATE
+#
+# Testing for error ER_CON_COUNT_ERROR alone causes this to
+# be printed in the result file:
+# - ERROR 08004: Too many connections
+# which in turn causes spurious test failures.
+#
+# To work around this, this scripts expect to see either
+# the error number ER_CON_COUNT_ERROR (it always does)
+# or the error number 9999 (it never does, this error does not exist).
+# The exact error number and SQLSTATE is not printed in the result file,
+# makig this test robust for both cases:
+# - ERROR 08004: Too many connections
+# - ERROR HY000: Too many connections
+
 --disable_query_log
---error ER_CON_COUNT_ERROR
+--error ER_CON_COUNT_ERROR, 9999
 connect (con5c,"127.0.0.1",quota,,test,$MASTER_MYPORT,);
 --enable_query_log
 
@@ -206,7 +228,7 @@ connect (con5c,"127.0.0.1",quota,,test,$
 --source ../include/hostcache_dump.inc
 
 --disable_query_log
---error ER_CON_COUNT_ERROR
+--error ER_CON_COUNT_ERROR, 9999
 connect (con5d,"127.0.0.1",quota,,test,$MASTER_MYPORT,);
 --enable_query_log
 

=== modified file 'mysql-test/suite/perfschema/t/hostcache_ipv6_max_con.test'
--- a/mysql-test/suite/perfschema/t/hostcache_ipv6_max_con.test	2012-02-06 09:13:43 +0000
+++ b/mysql-test/suite/perfschema/t/hostcache_ipv6_max_con.test	2012-03-01 10:44:16 +0000
@@ -198,8 +198,11 @@ select current_user();
 --connection default
 --source ../include/hostcache_dump.inc
 
+# About ER_CON_COUNT_ERROR,
+# See comments in hostcache_ipv4_max_con.test
+
 --disable_query_log
---error ER_CON_COUNT_ERROR
+--error ER_CON_COUNT_ERROR, 9999
 connect (con5c,"::1",quota,,test,$MASTER_MYPORT,);
 --enable_query_log
 
@@ -207,7 +210,7 @@ connect (con5c,"::1",quota,,test,$MASTER
 --source ../include/hostcache_dump.inc
 
 --disable_query_log
---error ER_CON_COUNT_ERROR
+--error ER_CON_COUNT_ERROR, 9999
 connect (con5d,"::1",quota,,test,$MASTER_MYPORT,);
 --enable_query_log
 

=== modified file 'sql/mysqld.cc'
--- a/sql/mysqld.cc	2012-02-28 09:11:34 +0000
+++ b/sql/mysqld.cc	2012-03-01 10:44:16 +0000
@@ -5578,6 +5578,18 @@ static void create_new_thread(THD *thd)
     mysql_mutex_unlock(&LOCK_connection_count);
 
     DBUG_PRINT("error",("Too many connections"));
+    /*
+      The server just accepted the socket connection from the network,
+      and we already have too many connections.
+      Note that the server knows nothing of the client yet,
+      and in particular thd->client_capabilities has not been negotiated.
+      ER_CON_COUNT_ERROR is normally associated with SQLSTATE '08004',
+      but sending a SQLSTATE in the network assumes CLIENT_PROTOCOL_41.
+      See net_send_error_packet().
+      The error packet returned here will only contain the error code,
+      with no sqlstate.
+      A client expecting a SQLSTATE will not find any, and assume 'HY000'.
+    */
     close_connection(thd, ER_CON_COUNT_ERROR);
     delete thd;
     statistic_increment(connection_errors_max_connection, &LOCK_status);

No bundle (reason: useless for push emails).
Thread
bzr push into mysql-trunk branch (marc.alff:3709 to 3710) Marc Alff5 Mar