(regression)

Problem was that partition pruning did not exclude the
last partition if the range was beyond it
(i.e. not using MAXVALUE)

Fix was to not include the last partition if the
partitioning function value was not within the partition
range.

mysql-test/r/partition_innodb.result:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Updated result
mysql-test/r/partition_pruning.result:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Updated result
mysql-test/t/partition_innodb.test:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Added test for pruning in InnoDB, since it does not show
  for MyISAM due to 'Impossible WHERE noticed after reading
  const tables'.
mysql-test/t/partition_pruning.test:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Added test
sql/sql_partition.cc:
  Bug#51830: Incorrect partition pruning on range partition
  (regression)
  
  Also increase the partition id if not inside the last partition
  (and no MAXVALUE is defined).
  
  Added comments and DBUG_ASSERT.

Spatial indexes were not checking for out-of-record condition in
the handler next command when the previous command didn't found
rows.

Fixed by making the rtree index to check for end of rows condition
before re-using the key from the previous search.

Fixed another crash if the tree has changed since the last search.
Added a test case for the other error.

Spatial indexes were not checking for out-of-record condition in
the handler next command when the previous command didn't found
rows.

Fixed by making the rtree index to check for end of rows condition
before re-using the key from the previous search.

Fixed another crash if the tree has changed since the last search.
Added a test case for the other error.

            consider clustered primary keys

Choosing a shortest index for the covering index scan,
the optimizer ignored the fact, that the clustered primary
key read involves whole table data.

The find_shortest_key function has been modified to
take into account that fact that a clustered PK has a
longest key of possible covering indices.


mysql-test/r/innodb_mysql.result:
  Test case for bug #39653.
mysql-test/t/innodb_mysql.test:
  Test case for bug #39653.
sql/sql_select.cc:
  Bug #39653: find_shortest_key in sql_select.cc does not
              consider clustered primary keys
  
  The find_shortest_key function has been modified to
  take into account that fact that a clustered PK has a
  longest key of possible covering indices.

 for ORDER BY on a TEXT or VARCHAR field" backported to 5.1.

If an outer query is broken, a subquery might not even get set up.
EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all
of the half-setup info.

We now catch this case and print as much as we have, as it doesn't cost us
anything (doesn't make regular execution slower).

backport from 5.1

mysql-test/r/explain.result:
  Show that EXPLAIN EXTENDED with subquery and illegal out query doesn't crash.
  Show also that SHOW WARNINGS will render an additional Note in the hope of
  being, well, helpful.
mysql-test/t/explain.test:
  If we have only half a query for EXPLAIN EXTENDED to print (i.e.,
  incomplete subquery info as outer query is illegal), we should
  provide the user with as much info as we easily can if they ask
  for it. What we should not do is crash when they come asking for
  help, that violates etiquette in some countries.
sql/item_subselect.cc:
  If the sub-query's actually set up, print it. Otherwise, elide.

      
This patch fixes some typos and poorly formulated sentences in
the output from mysqld --help --verbose.

Some of the problems described in the bug report are already
handled by the patch for Bug#49447, and are therefore not
included in this patch.

START SLAVE UNTIL MASTER ... specifies only SQL thread to stop.
rpl_slave_skip erronously deployed waiting for stop of both threads.

Corrected with deploying the correct macro.
Notice, earlier a similar bug@47749 was fixed in mysql-trunk.

mysql-test/suite/rpl/t/rpl_slave_skip.test:
  changing two waiting calls for offline of both threads into waiting for SQL to stop.

for same data when using bit fields

Problem: checksum for BIT fields may be computed incorrectly 
in some cases due to its storage peculiarity.

Fix: convert a BIT field to a string then calculate its checksum.


mysql-test/r/myisam.result:
  Fix for bug#51304: checksum table gives different results 
  for same data when using bit fields
    - test result.
mysql-test/t/myisam.test:
  Fix for bug#51304: checksum table gives different results 
  for same data when using bit fields
    - test case.
sql/sql_table.cc:
  Fix for bug#51304: checksum table gives different results 
  for same data when using bit fields
    - convert BIT fields to strings calculating its checksums
  as some bits may be saved among NULL bits in the record buffer.

disabling the test to not run on PB

mysql-test/t/mysql_upgrade.test:
  For execution, mostly testing the presence of the binary anyway.

POSIX standard, reinitialization of a pthread_once is a gray
area, but it is needed to support subsequent initializations
of the client library.

mysys/charset.c:
  Reinitialize a pthread_once_t variable.

A client doing multiple mysql_library_init() and
mysql_library_end() calls over the lifetime of the process may
experience lost character set data, potentially even a
SIGSEGV.

This patch reinstates the reloading of character set data when
a mysql_library_init() is done after a mysql_library_end().

Item_field::print method does not take into
account fields whose values may be null.
The fix is to print 'NULL' if field value is null.


mysql-test/r/explain.result:
  test case
mysql-test/r/func_str.result:
  result fix
mysql-test/r/having.result:
  result fix
mysql-test/r/select.result:
  result fix
mysql-test/r/subselect.result:
  result fix
mysql-test/r/union.result:
  result fix
mysql-test/t/explain.test:
  test case
sql/item.cc:
  print 'NULL' if field value is null.

Fixed a syntax error in mysqld_multi.sh

The problem was that the CSV storage engine does not support NULL
fields, yet in some early 5.1 version the log tables (general_log
and slow_log) were created with null fields. On top of this, when
altering a CSV table column, all fields of the table must be NOT
NULL otherwise the alteration fails.

The solution is to ensure that during upgrade all columns of the
log tables are NOT NULL.

mysql-test/r/log_tables_upgrade.result:
  Add test case result for Bug#49823.
mysql-test/std_data/bug49823.CSV:
  Sample data for test.
mysql-test/std_data/bug49823.frm:
  Add a CSV table which mimics the general_log table, except that
  it contains a nullable column.
mysql-test/t/log_tables_upgrade.test:
  Add test case for Bug#49823.
scripts/mysql_system_tables_fix.sql:
  Ensure that all columns of the log tables are NOT NULL.