When join buffers are employed no index scan for the first
table with grouping columns can be used.



mysql-test/r/join_cache.result:
  Added a test case for bug #664508.
  Sorted results for some other test cases.
mysql-test/t/join_cache.test:
  Added a test case for bug #664508.
  Sorted results for some other test cases.

After the patch for bug 663840 had been applied the test case for
bug 663818 triggered the assert introduced by this patch.
It happened because the the patch turned out to be incomplete:
the space needed for a key entry must be taken into account
for the record written into the buffer, and, for the next record
as well, when figuring out whether the record being written is
the last for the buffer or not. 

When adding a new record into the join buffer that is employed by
BNLH join algorithm the writing procedure JOIN_CACHE::write_record_data 
checks whether there is enough space for the record in the buffer.
When doing this it must take into account a possible new key entry
added to the buffer. It might happen, as it has been demonstrated by
the bug test case, that there is enough remaining space in the buffer
for the record, but not for the additional key entry for this record.
In this case the key entry overwrites the end of the record that might
cause a crash or wrong results.
Fixed by taking into account a possible addition of new key entry when
estimating the remaining free space in the buffer.

about the employed join algorithms.
Refactored constructors of the JOIN_CACHE* classes.

(Otherwise we get different EXPLAINs for xtradb and innodb plugin).

- Fix a crash in nested semi-join subquery processing

- When building multiple-equalities for HAVING, don't set JOIN::cond_equal, set
  join_having_equal instead. Setting JOIN::cond_equal based on HAVING makes 
  equality propagation data self-inconsistent

and mistakingly pulled in back for maria-5.1.50.

It should be turned on back when the tree for MWL#128 is merged
into the main 5.3 merge.

- post-merge fixes

Fixes for bugs found by running test case for LP#608369 "Page: 1 Found wrong page type 0' on CHECK TABLE EXTENDED"
Fixed overflow when using long --debug=xxxxxx line.
Fixed that "mysqld --disable-debug --debug" works.
Ensure that MariaDB doesn't start if the Aria engine didn't start and we are using Aria for temporary tables.
More DBUG_ASSERT() and more info in debug log.


dbug/dbug.c:
  Fixed crash in mysqld caused by an overflow when using long --debug=xxxxxx line
sql/mysqld.cc:
  Fixed that "mysqld --disable-debug --debug" works.
  Documented myisam-recover=OFF option
storage/maria/ha_maria.cc:
  Ensure that MariaDB doesn't start if the Aria engine didn't start and we are using Aria for temporary tables.
storage/maria/ma_delete.c:
  Added missing write of changed key on node page.
  This could fix LP#608369 "Page: 1 Found wrong page type 0' on CHECK TABLE EXTENDED"
  Changed so that we log page numbers (not positions)
  Added KEY_OP_DEBUG_2 log entry to get more debug information into the log
storage/maria/ma_key_recover.c:
  Changed so that we log page numbers (not positions)
  In case of wrong page information after index_redo, dump pages to debug log
storage/maria/ma_loghandler.h:
  Added KEY_OP_DEBUG_2
storage/maria/ma_search.c:
  Changed so that we log page numbers (not positions)
storage/maria/ma_write.c:
  Changed so that we log page numbers (not positions)

sql/sql_parse.cc:
  Make some not commonly used functions with big local variables to separate functions to make default stack usage smaller.
  Decrease size of db_buff[] (Was bigger than needed)
  Allocate current_global_status_var with malloc().
storage/maria/ha_maria.cc:
  Don't allocate HA_CHECK on stack (it's > 100K)
storage/maria/ma_check.c:
  Removed duplicated code

- Re-commit Monty's merge, partially fixed by Igor and SergeyP, 
  but still broken

- _ma_apply_redo_index: Assertion `page_offset != 0 && page_offset + length <= page_length' failed
Fixes one bug and one log assert when inserting rows:
- _ma_log_split: Assertion `org_length <= info->s->max_index_block_size' failed
- write_block_record:  Assertion '(data_length < MAX_TAIL_SIZE(block_size)' failed
Mark in recovery log where _ma_log_add() calls was done (for better debugging).

storage/maria/ma_bitmap.c:
  Don't write a head part on a tail page. (Caused an assert in write_block_record())
storage/maria/ma_delete.c:
  Mark in recovery log where _ma_log_add() calls was done
storage/maria/ma_key_recover.c:
  Mark in recovery log where _ma_log_add() calls was done
  Fixed not handled logging case for overfull index pages.
storage/maria/ma_key_recover.h:
  Mark in recovery log where _ma_log_add() calls was done
storage/maria/ma_loghandler.h:
  Mark in recovery log where _ma_log_add() calls was done
storage/maria/ma_rt_key.c:
  Mark in recovery log where _ma_log_add() calls was done
storage/maria/ma_write.c:
  Mark in recovery log where _ma_log_add() calls was done.
  Fixed wrong call to _ma_split_page() for overfull pages

Employed the same kind of optimization as in the fix for the cases
when join buffer is used.
The optimization performs early evaluation of the conditions from 
on expression with table references to only outer tables of
an outer join.

The reason for this was that some bitmap test functions changed the bitmap, which caused problems when the same bitmap was used by multiple threads.


include/my_bitmap.h:
  Changed order of elements to get better alignment.
mysys/my_bitmap.c:
  Change bitmap test functions to not modify the bitmap.
  Fixed compiler errors in test_bitmap

The fix aligns join_null_complements() with join_matching_records()
making both call generate_full_extensions().
There should not be any difference between how the WHERE clause
is applied to NULL-complemented records from a partial join and how
it is applied to other partially joined records:the latter happens in
join_matching_records(), precisely in generate_full_extensions().

the fix for bug 52636.

Added a possibility not to factor out the condition pushed to
the access index out of the condition pushed to a joined table.
This is useful for the condition pushed to the index when a hashed
join buffer for BKA is employed. In this case the index condition
may be false for some, but for all records with the same key.
So the condition must be checked not only after index lookup,
but after fetching row data as well, and it makes sense not to 
factor out the condition from the condition checked after reading
row data,
The bug happened because the condition pushed to an index always
was factor out from the condition pushed to the accessed table. 

******
Fixed bug #54539.
Added a possibility not to factor out the condition pushed to
the access index out of the condition pushed to a joined table.
This is useful for the condition pushed to the index when a hashed
join buffer for BKA is employed. In this case the index condition
may be false for some, but for all records with the same key.
So the condition must be checked not only after index lookup,
but after fetching row data as well, and it makes sense not to 
factor out the condition from the condition checked after reading
row data,
The bug happened because the condition pushed to an index always
was factor out from the condition pushed to the accessed table. 

Added a possibility not to factor out the condition pushed to
the access index out of the condition pushed to a joined table.
This is useful for the condition pushed to the index when a hashed
join buffer for BKA is employed. In this case the index condition
may be false for some, but for all records with the same key.
So the condition must be checked not only after index lookup,
but after fetching row data as well, and it makes sense not to 
factor out the condition from the condition checked after reading
row data,
The bug happened because the condition pushed to an index always
was factor out from the condition pushed to the accessed table. 

Applied the fix for bug #47217 from the mysql-6.0 codebase.
The patch adds not null predicates generated for the left parts
of the equality predicates used for ref accesses. This is done
for such predicates both in where conditions and on conditions.
For the where conditions the not null predicates were generated
but in 5.0/5.1 they actually never were used due to some lame
merge from 4.1 to 5.0. The fix for bug #47217 made these 
predicates to be used in the condition pushed to the tables.
Yet only this patch generates not null predicates for equality
predicated from on conditions of outer joins.
This patch introduces a performance regression that can be
observed on a test case from null_key.test. The regression
will disappear after the fix for bug #57024 from mariadb-5.1
is pulled into mariadb-5.3.
The patch contains many changes in the outputs of the EXPLAIN 
commands since generated not null predicates are considered as
parts of the conditions pushed to join tables and may add
'Usingwhere' in some rows of EXPLAINs where there used
to be no such comments.