Fixes a bug where bool* was used as an argument to a function where the parameter
was of type bool.

Update the result file to minor tweaks of the comments in the
test case.

Fix for bug #46947 "Embedded SELECT without FOR UPDATE is
causing a lock", with after-review fixes.

SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.

This was a regression which were introduced when fixing
bug 39843.

The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.

This patch tries to solve this problem by rethinking our
approach to how we handle locking for SELECT and subqueries.
Now we always set TL_READ_DEFAULT lock type for all cases
when we read data. When at open_tables() time this lock
is interpreted as TL_READ_NO_INSERT or TL_READ depending
on whether this statement as a whole or call to function
which uses particular table should be written to the
binary log or not (if yes then statement should be properly
serialized with concurrent statements and stronger lock
should be acquired).

Test coverage is added for both InnoDB and MyISAM.

This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.
In 4.1 the server would use a snapshot InnoDB read for 
subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE
statements, regardless of whether the binary log is on or off.
If the user required a different type of read (i.e. locking read),
he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE
clause for each individual subquery.
On of the patches for 5.0 broke this behaviour (which was not documented
or tested), and started to use locking reads fora all subqueries in SELECT ... 
FOR UPDATE/IN SHARE MODE. This patch restored 4.1 behaviour.

The bug was a side effect of WL#5030 (fix header files) and
WL#5161 (CMake).

The problem was that CMake-generated config.h (and my_config.h
as a copy of it) had a header guard. GNU autotools-generated
[my_]config.h did not. During WL#5030 the order of header files
was changed, so the following started to happen (using GNU autotools,
in embedded server):
  - my_config.h included, defining HAVE_OPENSSL
  - my_global.h included, un-defining  HAVE_OPENSSL
  - zlib.h included, including config.h,
    defining HAVE_OPENSSL again.

The fix is to change the order of header file, moving zlib.h
to the top of the header list. More proper fix would be to wrap
unguarded auto-generated [my_]config.h by guarded non-generated
header file.

          transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW

Post-merge fixes.

Removing traces of mysql_priv.h from comments and other
non-source files that were missed before.

          transaction
BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW

Before the WL#2687 and BUG#46364, every non-transactional change that happened
after a transactional change was written to trx-cache and flushed upon
committing the transaction. WL#2687 and BUG#46364 changed this behavior and
non-transactional changes are now written to the binary log upon committing
the statement.

A binary log event is identified as transactional or non-transactional through
a flag in the Log_event which is set taking into account the underlie storage
engine on what it is stems from. In the current bug, this flag was not being
set properly when the DROP TEMPORARY TABLE was executed.

However, while fixing this bug we figured out that changes to temporary tables
should be always written to the trx-cache if there is an on-going transaction.
Otherwise, binlog events in the reversed order would be produced.

Regarding concurrency, keeping changes to temporary tables in the trx-cache is
also safe as temporary tables are only visible to the owner connection.

In this patch, we classify the following statements as unsafe:
   1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam

   3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam

On the other hand, the following statements are classified as safe:

   1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp

   2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb

The patch also guarantees that transactions that have a DROP TEMPORARY are
always written to the binary log regardless of the mode and the outcome:
commit or rollback. In particular, the DROP TEMPORARY is extended with the
IF EXISTS clause when the current statement logging format is set to row.

Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there
are temporary tables but the contrary is not possible.

Bug#30977 Concurrent statement using stored function and
          DROP FUNCTION breaks SBR
Bug#48246 assert in close_thread_table

back into the development branches.

mysql-trunk-bugfixing (bug 52341).

mysql-trunk-bugfixing.

This assertion could be triggered during execution of OPTIMIZE TABLE for
InnoDB tables. As part of optimize for InnoDB tables, the table is recreated
and then opened again. If the reopen failed for any reason, the assertion
would be triggered. This could for example be caused by a concurrent DROP
TABLE executed by a different connection. The reason for the assertion was
that any failures during reopening were ignored.

This patch fixes the problem by making sure that the result of reopening the
table is checked and that any error messages are sent to the client.

Test case added to innodb_mysql_sync.test.

This was a deadlock between CREATE/ALTER/DROP EVENT and a query
accessing both the mysql.event table and I_S.GLOBAL_VARIABLES.

The root of the problem was that the LOCK_event_metadata mutex was
used to both protect the "event_scheduler" global system variable
and the internal event data structures used by CREATE/ALTER/DROP EVENT.

The deadlock would occur if CREATE/ALTER/DROP EVENT held
LOCK_event_metadata while trying to open the mysql.event table,
at the same time as the query had mysql.event open, trying to
lock LOCK_event_metadata to access "event_scheduler".

This bug was fixed in the scope of Bug#51160 by using only
LOCK_global_system_variables to protect "event_scheduler".
This makes it so that the query above won't lock LOCK_event_metadata,
thereby preventing this deadlock from occuring.

This patch contains no code changes.
Test case added to lock_sync.test.

            my_global.h first

We may end up with a compilation failure on certain platforms
because zlib.h is included before my_global.h.

Fixed by moving zlib.h inclusion down after my_global.h.

            e.g.MYSQL_AUDIT_GENERAL_ERROR

General audit API (MYSQL_AUDIT_GENERAL_CLASS) didn't expose event
subclass to plugins.

This patch exposes event subclass to plugins via
struct mysql_event_general::event_subclass.

This change is not compatible with existing general audit plugins.
Audit interface major version has been incremented.

           even if myisam-recover is OFF

The problem was that a corrupted MyISAM table was auto repaired
even if the myisam_recover_options server variable (or the 
myisam_recover option) was set to OFF.

The reason was that the auto_repair() function, which is supposed
to say if auto repair is to be used, did not use the server variable
setting correctly. This bug was a regression introduced by WL#4738.

This patch fixes the problem by making sure auto_repair() returns
FALSE if myisam_recover_options is set to OFF.

Test case added to myisam.test.

The problem was that the code that works with stored routines was present
in mysql_system_tables.sql. This is wrong because until upgrade is finished,
stored routines may be (and were) not available.

The fix is to move that code to the end of mysql_system_tables_fix.sql.

           for write by another connection

The problem was that if a table was locked in one connection by
LOCK TABLES ... WRITE, REPAIR TABLE or OPTIMIZE TABLE, SHOW CREATE
TABLE from another connection would be blocked. As SHOW CREATE TABLE
only reads metadata about the table, such blocking is not needed.

The problem was that when SHOW CREATE TABLE tried to get a metadata
lock on the table in order to open it, it used the wrong type of
metadata lock request. It used MDL_SHARED_READ which is used when
the intent is to read both table metadata and table data. Instead
it should have used MDL_SHARED_HIGH_PRIO which signifies an intent
to only read metadata.

This patch fixes the problem by making sure SHOW CREATE TABLE uses
the MDL_SHARED_HIGH_PRIO metadata lock request type when trying to
open the table. The patch also fixes a similar problem with the
mysql_list_fields API call.

Test case added to show_check.test.

           during rqg_mdl_deadlock test

The problem was that if two connection threads simultaneously tries
to execute "SET GLOBAL EVENT_SCHEDULER = OFF", one of them could
hang waiting for the scheduler to stop.

The first connection thread would kill the event scheduler thread
and then start waiting for it to exit. The second connection thread
would then find the event scheduler thread in the process of exiting
and also wait for it to exit. However, since the event scheduler 
thread used signal to wake only one waiting thread, the other connection
thread would be left waiting.

This bug was a regression introduced by the fix for Bug#51160.
Before #51160 it was not possible for two connection threads to 
try to stop the event scheduler thread simultaneously.

This patch fixes the problem my making sure the event scheduler
thread uses broadcast to notify all waiters that it is exiting.

No test case added as this would require adding debug sync points
to parts of the code where sync points are currently not used.
The patch has been tested with the non-deterministic test case
from the bug description as well as using the RQG.

Allow stored procedure variables in LIMIT clause.
Only allow variables of INTEGER types. 
Handle negative values by means of an implicit cast to UNSIGNED 
(similarly to prepared statement placeholders).
Add tests.
Make sure replication works by not doing NAME_CONST substitution
for variables in LIMIT clause.
Add replication tests.

ChangeSet@1.2703, 2007-12-07 09:35:28-05:00, cmiller@zippy.cornsilk.net +40 -0
Bug#13174: SHA2 function
Patch contributed from Bill Karwin, paper unnumbered CLA in Seattle

Implement SHA2 functions.

Chad added code to make it work with YaSSL.  Also, he removed the 
(probable) bug of embedded server never using SSL-dependent 
functions.  (libmysqld/Makefile.am didn't read ANY autoconf defs.)

Function specification:
  SHA2( string cleartext, integer hash_length ) 
    -> string hash, or NULL
where hash_length is one of 224, 256, 384, or 512.  If either is 
NULL or a length is unsupported, then the result is NULL.  The 
resulting string is always the length of the hash_length parameter
or is NULL.

Include the canonical hash examples from the NIST in the test
results.
---
Polish and address concerns of reviewers.

pthread_t is not defined unless my_pthread.h is included.

Problem: Segmentation fault in add_group_and_distinct_keys() when accessing
field of what is assumed to be an Item_field object.

Cause: In case of views, the item added to list by is_indexed_agg_distinct() 
was not of type Item_field, but Item_ref.

Resolution:  Add the real Item_field object, the one referred to by 
Item_ref object, to the list, instead.