List:Commits« Previous MessageNext Message »
From:Ole John Aske Date:December 1 2010 9:36pm
Subject:bzr push into mysql-5.1-telco-7.0-spj-scan-vs-scan branch
(ole.john.aske:3381 to 3382) Bug#58628
View as plain text  
 3382 Ole John Aske	2010-12-01
      Addendum patch for bug#58628: Update of result file due 
      to changed (improved) behaviour when constructing a REF 
      key from 'out of bound' values. 
      
      As the main fix will cause failing const key value ::copy() 
      to be reevaluate inside JOIN::exec(), we will detect out of bound
      values (which will form an illegal/undefined REF key) before 
      executing the access request. Previously these const REF keys 
      was produced by JOIN::optimize() and any conversion/range errors 
      was ignored. - Possibly causing undefined keys to be produced.
      
      These access request may then be ignored wo/ a Handler_read_key request
      being executed.

    modified:
      mysql-test/r/update.result
 3381 Ole John Aske	2010-12-01
      SPJ-scan-scan: Cherry picked fix for bug#58628 Incorrect result for 'WHERE NULL NOT IN (<subquery>)
      
            create_ref_for_key() allowed any constant part of a REF key to be evaluated
            and stored into the 'key_buff' during ::optimize(). These 'store_key*' was
            *not* kept in ref.key_copy[] as they where constant and we assumed we
            would not have to reevaluate them during JOIN::exec()
      
            However, during execute NULL values in REF key has to be detected as they may
            need special attention - as in 'Full scan on NULL key'. This is done by
            subselect_uniquesubquery_engine::copy_ref_key() which check if any keyparts
            evaluated to a NULL-value.
      
            As we didn't keep a store_key for a constant value, a NULL-constant was not detected
            by subselect_uniquesubquery_engine::copy_ref_key() !
      
            This fixs modifies create_ref_for_key() to check if a NULL-value constant
            was produced - In these cases it keeps the store_key, which then will be
            reevaluated in JOIN::exec() and trigger correct handling of NULL-valued keys.

    modified:
      mysql-test/r/func_in.result
      mysql-test/t/func_in.test
      sql/sql_select.cc
      sql/sql_select.h
=== modified file 'mysql-test/r/update.result'
--- a/mysql-test/r/update.result	2010-07-19 09:03:52 +0000
+++ b/mysql-test/r/update.result	2010-12-01 21:35:17 +0000
@@ -404,7 +404,7 @@ user_id
 show status like '%Handler_read%';
 Variable_name	Value
 Handler_read_first	0
-Handler_read_key	1
+Handler_read_key	0
 Handler_read_next	0
 Handler_read_prev	0
 Handler_read_rnd	0
@@ -414,7 +414,7 @@ user_id
 show status like '%Handler_read%';
 Variable_name	Value
 Handler_read_first	0
-Handler_read_key	2
+Handler_read_key	0
 Handler_read_next	0
 Handler_read_prev	0
 Handler_read_rnd	0
@@ -423,7 +423,7 @@ UPDATE t1 SET user_id=null WHERE request
 show status like '%Handler_read%';
 Variable_name	Value
 Handler_read_first	0
-Handler_read_key	3
+Handler_read_key	1
 Handler_read_next	0
 Handler_read_prev	0
 Handler_read_rnd	0
@@ -432,7 +432,7 @@ UPDATE t1 SET user_id=null WHERE request
 show status like '%Handler_read%';
 Variable_name	Value
 Handler_read_first	0
-Handler_read_key	3
+Handler_read_key	1
 Handler_read_next	0
 Handler_read_prev	0
 Handler_read_rnd	0


Attachment: [text/bzr-bundle] bzr/ole.john.aske@oracle.com-20101201213517-2ls122fz6roancu1.bundle
Thread
bzr push into mysql-5.1-telco-7.0-spj-scan-vs-scan branch(ole.john.aske:3381 to 3382) Bug#58628Ole John Aske1 Dec