Problem: "read-only" option ignored if it's enabled in
the command line (or in the config file).

Fix: sync opt_readonly (which is used for checks) with 
read_only (global var) when all server options are handled.


mysql-test/r/bug58669.result:
  Fix for bug #58669: read_only not enforced on 5.5.x
    - test result.
mysql-test/t/bug58669-master.opt:
  Fix for bug #58669: read_only not enforced on 5.5.x
    - test case.
mysql-test/t/bug58669.test:
  Fix for bug #58669: read_only not enforced on 5.5.x
    - test case.
sql/mysqld.cc:
  Fix for bug #58669: read_only not enforced on 5.5.x
    - sync opt_readonly boolean with read_only boolean
  in the get_options().
sql/mysqld.h:
  Fix for bug #58669: read_only not enforced on 5.5.x
    - sync opt_readonly boolean with read_only boolean
  in the get_options().
sql/sys_vars.cc:
  Fix for bug #58669: read_only not enforced on 5.5.x
    - sync opt_readonly boolean with read_only boolean
  in the get_options().

The problem was that mysql_upgrade failed because DROP DATABASE
refused to drop the 'performance_schema' database when the 
mysql.proc table definition was made temporarily invalid
by dump import.

This patch fixes the problem by adding the error resulting
from opening a damaged mysq.proc table (ER_CANNOT_LOAD_FROM_TABLE),
to the list of errors DROP DATABASE will ignore when trying
to lock stored procedures and functions before deletion.

This problem was a regression introduced by the patch for
Bug#57663.

Test case added to sp-destruct.test.

MSI: Only call custom action if REMOVE=ALL is specified, this avoids accidential removing services if  feature states are modified (reported by Iggy)

Null-merging revision
'revid: joerg@mysql.com-20101102213229-lyd8tl5gr40dotck'
(Bug_57916: Fix the naming of the proxy_priv table)
from mysql-5.5.7-rc-release.

The patch is already in mysq-5.5.8-release
(revid: georgi.kodinov@oracle.com-20101102154526-coc3muh4mlw91ti8)

Null-merging revision
'revid: kevin.lewis@oracle.com-20101102151655-b9oe4ii46szw7vx1'
(Bug_57904 - Only one INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS was displayed
per table from Innodb) from mysql-5.5.7-rc-release.

The patch is already in mysql-5.5.8-release
(revid: kevin.lewis@oracle.com-20101102150314-a3jx98sg7wm3emge).

- Mark main.gis experimental

Reverting the patch.

Post-fix:
  Reverting the "utf16_bin did not sort supplementary characters
  between U+D700 and U+E000" part. We'll use code-point order.

Committing on behalf of Alexander Barkov.

Fix formatting issues in README file.

EXCEPTIONS-CLIENT from all the places.

If mysqltest dies, mtr waits to see if mysqld dies too within 100ms
But in that case, it should not care about expected crash
Fix: jump past the code that checks the expect file

While here, support supplying a '-j' flag to make(1) from
the environment.

Done as suggested
Also tested from src build directory

See bug #58416.

In case of low memory sort buffer QUICK_INDEX_MERGE_SELECT creates
temporary file where is stores row ids which meet QUICK_SELECT ranges
except of clustered pk range, clustered range is processed separately.
In init_read_record we check if temporary file is used and choose
appropriate record access method. It does not take into account that
temporary file contains partial result in case of QUICK_INDEX_MERGE_SELECT
with clustered pk range.
The fix is always to use rr_quick if QUICK_INDEX_MERGE_SELECT
with clustered pk range is used.


mysql-test/suite/innodb/r/innodb_mysql.result:
  test case
mysql-test/suite/innodb/t/innodb_mysql.test:
  test case
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
  test case
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
  test case
sql/opt_range.h:
  added new method
sql/records.cc:
  The fix is always to use rr_quick if QUICK_INDEX_MERGE_SELECT
  with clustered pk range is used.

5.0-security --> 5.1-security

> revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
> parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: 5.1-security
> timestamp: Tue 2010-08-24 14:35:48 +0400
> message:
>   Bug #55568: user variable assignments crash server when used
>               within query
>   
>   The server could crash after materializing a derived table
>   which requires a temporary table for grouping.
>   
>   When destroying the temporary table used to execute a query for
>   a derived table, JOIN::destroy() did not clean up Item_fields
>   pointing to fields in the temporary table. This led to
>   dereferencing a dangling pointer when printing out the items
>   tree later in the outer SELECT.
>   
>   The solution is an addendum to the patch for bug37362: in
>   addition to cleaning up items in tmp_all_fields3, do the same
>   for items in tmp_all_fields1, since now we have an example
>   where this is necessary.


sql/field.cc:
  Make sure field->table_name is not set to NULL in
  Field::make_field() to avoid assertion failure in 
  Item_field::make_field() after cleaning up items
  (the assertion fired in udf.test when running
  the test suite with the patch applied).
sql/sql_select.cc:
  In addition to cleaning up items in tmp_all_fields3, do the
  same for items in tmp_all_fields1.
  Introduce a new helper function to avoid code duplication.
sql/sql_select.h:
  Introduce a new helper function to avoid code duplication in
  JOIN::destroy().

mysql-test/suite/sys_vars/t/shared_memory_base_name_basic.test:
  The server shared memory name is located in the server's
  temporary directory, not in the mysqltest one.
sql/sql_show.cc:
  */ ends a comment, add space to avoid problems.