the fix. 

Evaluate "NULL IN (SELECT ...)" in a special way: Disable pushed-down 
conditions and their "consequences": 
 = Do full table scans instead of unique_[index_subquery] lookups.
 = Change appropriate "ref_or_null" accesses to full table scans in
   subquery's joins.
Also cache value of NULL IN (SELECT ...) if the SELECT is not correlated 
wrt any upper select.


mysql-test/r/subselect.result:
  BUG#8804: wrong results for NULL IN (SELECT ...): 
   - Updated test results
sql/item.h:
  BUG#8804: wrong results for NULL IN (SELECT ...): 
   - Added comments
sql/item_cmpfunc.cc:
  BUG#8804: wrong results for NULL IN (SELECT ...): 
  Made Item_in_optimizer to:
  - cache the value of "NULL IN (uncorrelated select)"
  - Turn off pushed-down predicates when evaluating "NULL IN (SELECT ...)"
sql/item_cmpfunc.h:
  BUG#8804: wrong results for NULL IN (SELECT ...): 
  - Made Item_in_optimizer cache the value of "NULL IN (uncorrelated select)"
  - Added comments
sql/item_subselect.cc:
  BUG#8804: wrong results for NULL IN (SELECT ...):
  - When needed, wrap the predicates we push into subquery into an 
    Item_func_trig_cond so we're able to turn them off when evaluating 
    NULL IN (SELECT ...).
  - Added code to evaluate NULL IN (SELECT ...) in a special way:
    = In [unique_]index_subquery, do full table scan to see if there 
      are any rows.
    = For other subqueries, change ref[_or_null] to ALL if the
      ref[_or_null] was created from pushed-down predicate.
sql/item_subselect.h:
  BUG#8804: wrong results for NULL IN (SELECT ...):
  - Added Item_subselect::is_correlated
  - Added comments
sql/records.cc:
  BUG#8804: wrong results for NULL IN (SELECT ...):
  - Make rr_sequential() non-static
sql/sql_lex.cc:
  BUG#8804: wrong results for NULL IN (SELECT ...):
  - Added st_select_lex::is_correlated and Item_subselect::is_correlated.
sql/sql_lex.h:
  BUG#8804: wrong results for NULL IN (SELECT ...):
  - Added st_select_lex::is_correlated
sql/sql_select.cc:
  BUG#8804: wrong results for NULL IN (SELECT ...):
  - Added KEY_FIELD::outer_ref to keep track of which ref accesses are 
    created from predicates that were pushed down into the subquery.
sql/sql_select.h:
  BUG#8804: wrong results for NULL IN (SELECT ...):
  - Added KEYUSE::outer_ref
mysql-test/r/subselect3.result:
  New BitKeeper file ``mysql-test/r/subselect3.result''
mysql-test/t/subselect3.test:
  New BitKeeper file ``mysql-test/t/subselect3.test''

into  rurik.mysql.com:/home/igor/mysql-5.0-opt

into  rurik.mysql.com:/home/igor/mysql-5.0-opt


sql/item_subselect.cc:
  Auto merged
mysql-test/r/subselect.result:
  SCCS merged
mysql-test/t/subselect.test:
  SCCS merged

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt


sql/sql_base.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt


mysql-test/r/myisam.result:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt


sql/sql_base.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged

If elements a not top-level IN subquery were accessed by an index and 
the subquery result set included  a NULL value then the quantified
predicate that contained the subquery was evaluated to NULL when 
it should return a non-null value.


mysql-test/r/subselect.result:
  Added a test case for bug #23478.
mysql-test/t/subselect.test:
  Added a test case for bug #23478.

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines


myisam/sort.c:
  Auto merged
mysql-test/r/repair.result:
  Auto merged
mysql-test/t/repair.test:
  Auto merged
sql/sql_base.cc:
  Use local.

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt


sql/sql_select.cc:
  Auto merged
mysql-test/r/olap.result:
  SCCS merged

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt


mysql-test/r/merge.result:
  Auto merged
mysql-test/r/myisam.result:
  Auto merged
mysql-test/r/select.result:
  Auto merged
mysql-test/r/view.result:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/item_cmpfunc.h:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/opt_range.cc:
  Auto merged
sql/opt_range.h:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_update.cc:
  Auto merged
sql/table.cc:
  Auto merged

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines


mysql-test/r/repair.result:
  Manual merge.
mysql-test/t/repair.test:
  Manual merge.

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt


sql/sql_select.cc:
  Auto merged

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines

Backport from 5.1.
Raised STACK_MIN_SIZE for Debian GNU/Linux Sid,
Linux kernel 2.6.16,
gcc version 3.3.6 (Debian 1:3.3.6-13),
libc6-dbg 2.3.6.ds1-4,
Pentium4 (x86),
BUILD/compile-pentium-debug-max
Raised about 100 Bytes above the required minimum.

into  chilla.local:/home/mydev/mysql-5.0-merge


include/my_sys.h:
  Auto merged
sql/sql_select.cc:
  Auto merged

into  chilla.local:/home/mydev/mysql-5.0-merge


sql/sql_select.cc:
  Auto merged

into  chilla.local:/home/mydev/mysql-4.1-merge

into  mysql.com:/data0/bk/mysql-5.0-kt

Repair table could crash a server if there is not sufficient
memory (myisam_sort_buffer_size) to operate. Affects not only
repair, but also all statements that use create index by sort:
repair by sort, parallel repair, bulk insert.

Return an error if there is not sufficient memory to store at
least one key per BUFFPEK.

Also fixed memory leak if thr_find_all_keys returns an error.


myisam/sort.c:
  maxbuffer is number of BUFFPEK-s for repair. It is calculated
  as records / keys. keys is number of keys that can be stored
  in memory (myisam_sort_buffer_size). There must be sufficient
  memory to store both BUFFPEK-s and keys. It was checked
  correctly before this patch. However there is another
  requirement that wasn't checked: there must be sufficient
  memory for at least one key per BUFFPEK, otherwise repair
  by sort/parallel repair cannot operate.
  
  Return an error if there is not sufficient memory to store at
  least one key per BUFFPEK.
  
  Also fixed memory leak if thr_find_all_keys returns an error.
mysql-test/r/repair.result:
  A test case for BUG#23175.
mysql-test/t/repair.test:
  A test case for BUG#23175.

into  sunlight.local:/local_work/14959-bug-5.0-opt-mysql

  Cleanup of fix for bug#14959.


sql/sql_rename.cc:
  Cleanup of fix for bug#14959.

into  rurik.mysql.com:/home/igor/mysql-5.0-opt


sql/sql_select.cc:
  Auto merged

into  rurik.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug19579


mysql-test/t/select.test:
  Auto merged
sql/sql_select.cc:
  Auto merged
mysql-test/r/select.result:
  SCCS merged

into  macbook.gmz:/Users/kgeorge/mysql/work/B21798-5.0-opt-merge


sql/mysql_priv.h:
  Auto merged
sql/sql_delete.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/sql_table.cc:
  Auto merged
sql/sql_update.cc:
  Auto merged
mysql-test/r/subselect.result:
  merge fixes for bug 21798
mysql-test/t/subselect.test:
  merge fixes for bug 21798

            list using a function
When executing dependent subqueries they are re-inited and re-exec() for 
each row of the outer context.
The cause for the bug is that during subquery reinitialization/re-execution,
the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
and the local variable in 'sortorder' in create_sort_index(), which is
allocated by make_unireg_sortorder().
Care must be taken not to allocate anything into the thread's memory pool
while re-initializing query plan structures between subquery re-executions.
All such items mush be cached and reused because the thread's memory pool
is freed at the end of the whole query.
Note that they must be cached and reused even for queries that are not 
otherwise cacheable because otherwise it will grow the thread's memory 
pool every time a cacheable query is re-executed. 
We provide additional members to the JOIN structure to store references 
to the items that need to be cached.


mysql-test/r/subselect.result:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - test case
mysql-test/t/subselect.test:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - test case
sql/mysql_priv.h:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - cache the entities allocated in the threads memory pool by
     JOIN::exec ().
sql/sql_delete.cc:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's 
     memory pool by JOIN::exec ().
sql/sql_select.cc:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's 
     memory pool by JOIN::exec ().
sql/sql_select.h:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's 
     memory pool by JOIN::exec ().
sql/sql_table.cc:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's 
     memory pool by JOIN::exec ().
sql/sql_update.cc:
  Bug#21798: memory leak during query execution with subquery in column
              list using a function
   - cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's 
     memory pool by JOIN::exec ().

into  macbook.gmz:/Users/kgeorge/mysql/work/B22367-5.0-opt-merge


include/my_base.h:
  Auto merged
mysql-test/r/select.result:
  merge of 5.0-opt to 22367
mysql-test/t/select.test:
  merge of 5.0-opt to 22367

into  chilla.local:/home/mydev/mysql-4.1-bug12240


sql/sql_select.cc:
  Auto merged

account predicates that become sargable after reading const tables.
In some cases this resulted in choosing non-optimal execution plans.
Now info of such potentially saragable predicates is saved in
an array and after reading const tables we check whether this
predicates has become saragable.



mysql-test/r/select.result:
  Added a test case for bug #19579.
mysql-test/t/select.test:
  Added a test case for bug #19579.
sql/item_cmpfunc.cc:
  Fixed bug #19579: at range analysis optimizer did not take into 
  account predicates that become sargable after reading const tables.
  Added a counter of between predicates.
sql/sql_base.cc:
  Fixed bug #19579: at range analysis optimizer did not take into 
  account predicates that become sargable after reading const tables.
  Added a counter of between predicates.
sql/sql_lex.cc:
  Fixed bug #19579: at range analysis optimizer did not take into 
  account predicates that become sargable after reading const tables.
  Added a counter of between predicates.
sql/sql_lex.h:
  Fixed bug #19579: at range analysis optimizer did not take into 
  account predicates that become sargable after reading const tables.
  Added a counter of between predicates.
sql/sql_select.cc:
  Fixed bug #19579: at range analysis optimizer did not take into 
  account predicates that become sargable after reading const tables.
  Now info of such potentially saragable predicates is saved in
  an array and after reading const tables we check whether this
  predicates has become saragable.

into  rakia.(none):/home/kgeorge/mysql/autopush/B22342-5.0-opt


sql/opt_range.cc:
  Auto merged

 When using index for group by and range access the server isolates    
 a set of ranges based on the conditions over the key parts of the
 index used. Then it uses only the ranges over the GROUP BY fields to
 jump from one group to another. Since the GROUP BY fields may form a
 prefix over the index, we may use only a prefix of the ranges produced
 by the range optimizer.
 Each range contains a notion on whether it includes its border values.
 The problem is that when using a range prefix, the last range is open
 because it assumes that there is a range on the next keypart. Thus when
 we use a prefix range as it is, it excludes all border values.
 The solution is when ignoring the suffix of the range conditions 
 (to jump over the GROUP BY prefix only) the server must change the 
 remaining intervals so they always contain their borders, e.g. 
 if the whole range was :
 (1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make
 (1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means :
 a < c1 OR (a = c1 AND b < c2).


mysql-test/r/group_min_max.result:
  Bug #22342: No results returned for query using max and group by
   - test case
mysql-test/t/group_min_max.test:
  Bug #22342: No results returned for query using max and group by
   - test case
sql/opt_range.cc:
  Bug #22342: No results returned for query using max and group by
   - open the intervals for prefix select when there are more conditions
     than used for the prefix search.
sql/opt_range.h:
  Bug #22342: No results returned for query using max and group by
   - open the intervals for prefix select when there are more conditions
     than used for the prefix search.

into  chilla.local:/home/mydev/mysql-5.0-bug12240


sql/sql_select.cc:
  Auto merged

             strings
MySQL is setting the flag HA_END_SPACE_KEYS for all the keys that reference
text or varchar columns with collation different than binary.
This was done to handle correctly the situation where a lookup on such a key
may return more than 1 row because of the presence of many rows that differ
only by the amount of trailing space in the table's string column.
Inserting such values however appears to violate the unique checks on 
INSERT/UPDATE. Thus that flag must not be set as it will prevent the optimizer
from choosing a faster access method.
This fix removes the setting of the HA_END_SPACE_KEYS flag.


include/my_base.h:
  Bug #22367: Optimizer uses ref join type instead of eq_ref for simple join on 
               strings
   - disabled HA_END_SPACE_KEY as it's no longer needed
mysql-test/r/func_str.result:
  Bug #22367: Optimizer uses ref join type instead of eq_ref for simple join on 
               strings
   - fixed explain in an existing case
mysql-test/r/merge.result:
  Bug #22367: Optimizer uses ref join type instead of eq_ref for simple join on 
               strings
   - fixed explain in an existing case
mysql-test/r/select.result:
  Bug #22367: Optimizer uses ref join type instead of eq_ref for simple join on 
               strings
   - test case
mysql-test/r/subselect.result:
  Bug #22367: Optimizer uses ref join type instead of eq_ref for simple join on 
               strings
   - fixed explain in an existing case
mysql-test/t/select.test:
  Bug #22367: Optimizer uses ref join type instead of eq_ref for simple join on 
               strings
   - test case

into  macbook.gmz:/Users/kgeorge/mysql/work/B14019-5.0-opt