via mysqld_safe

Plugin dir was set to a hard-coded path instead of relative the base dir.

This patch fixes this by using a path relative the basedir instead of the
plugin directory indicated by the configuration.

      
The bug happened under the following condition:
  - there was a user variable of type REAL, containing NULL value
  - there was a table with a NOT_NULL column of any type but REAL, having
    default value (or auto increment);
  - a row was inserted into the table with the user variable as value.
    A warning was emitted here.

The problem was that handling of NULL values of REAL type was not properly
implemented: it didn't expect that REAL NULL value can be assigned to other
data type.

Basically, the problem was that set_field_to_null() was used instead of
set_field_to_null_with_conversions().

The fix is to use the right function, or more generally, to allow conversion of
REAL NULL values to other data types.

  
  Problem:
  item->name was NULL for Item_user_var_as_out_param
  which made strcmp(something, item->name) crash in the LOAD XML code.
  
  Fix:
  - item_func.h: Adding set_name() in constuctor for Item_user_var_as_out_param
  - sql_load.cc: Changing the condition in write_execute_load_query_log_event() which
  distiguished between Item_user_var_as_out_param and Item_field
  from
    if (item->name == NULL)
  to
    if (item->type() == Item::FIELD_ITEM)
  - loadxml.result, loadxml.test: adding tests

Problem: after introduction of "WL#2649 Number-to-string conversions"

This query:
  SET NAMES cp850; -- Or any other non-latin1 ASCII-based character set
  SELECT * FROM t1
  WHERE datetime_column='2010-01-01 00:00:00'
started to add extra character set conversion: 
  SELECT * FROM t1
  WHERE CONVERT(datetime_column USING cp850)='2010-01-01 00:00:00';

so index on DATETIME column was not used anymore.
Fix:
  avoid convertion of NUMERIC/DATETIME items
  (i.e. those with derivation DERIVATION_NUMERIC).

There were two problems here:
  1. misleading error message
  2. abusing KILL QUERY in the test case

1. The server reported "'DELETE FROM t1' failed: 1689: Wait on a lock was
aborted due to a pending exclusive lock", while the proper error message
should be "'DELETE FROM t1' failed: 1317: Query execution was interrupted".

The problem is that the server has two different flags for
signalling that a query is being killed: THD::killed and
mysys_var::abort. The test case triggers a race: sometimes
mysys_var::abort is set earlier than THD::killed. That leads
to the following situation:

  - thr_lock() checks mysys_var::abort and returns error status,
    since mysys_var::abort is set;

  - the caller (mysql_lock_tables()) gets an error from thr_lock(),
    but THD::killed is not set, so it decides that thr_lock() couldn't
    get a lock due to a pending exclusive lock.

This is a known issue with the server and it's not going to be fixed soon.

5.5 differs from 5.1 here as follows: when thr_lock() returns an error:
  - 5.1 continues trying thr_lock() until success;
  - 5.5 propagates the error

2. The test case uses KILL QUERY is a highly concurent environment.

The fix is to wait for the dying statement to rest in peace before
executing another DELETE FROM t1.

thread_temporary_used is not initialized causing
valgrind's warnings.

Clarified error messages related to unsafe statements:
 - avoid the internal technical term "row injection"
 - use 'binary log' instead of 'binlog'
 - avoid the word 'unsafeness'

Stored routine DDL statements use statement-based replication
regardless of the current binlog format. The problem here was
that if a DDL statement failed during metadata lock acquisition
or opening of mysql.proc, the binlog format would not be reset
before returning. So the following DDL or DML statements are 
binlogged with a wrong binlog format, which causes the slave 
to stop.

The problem can be resolved by grabbing an exclusive MDL lock firstly
instead of clearing the current binlog format. So that the binlog
format will not be affected when the lock grab returns directly with
an error. The same way is taken to open a proc table for update.

           parallel mode
      
The failure has nothing to do with parallel, but rather on the
order the tests are executed. In this case, the test
binlog_tmp_table (lets call it test2) was not ensuring that the
binary logs would be reset when it started. Later the test issues
a mysqlbinlog .../master-bin.000002 | mysql ... If the test that
was executed before this one (lets call it test1) had issued a
flush logs, then the file in use in test1 (master-bin.000002)
would not actually match the one that was expected. Eventually,
this would cause the statements logged in test1 to be replayed,
instead of the ones logged in the beginning of test2.
    
We fix this by:
  1. adding RESET MASTER to the beginning of binlog_tmp_table
  2. setting dynamically the file to use in binlog_tmp_table
     
Only #1 was needed, but the two make the tests cases more robust.

      
The problem is that message resource  (message.rc) is compiled as part of static library
sql.lib rather than with executable mysqld.exe. resource files do not work in static
libraries.
      
The fix is to add message.rc to mysqld.exe source files list.

Statements with CONNECTION_ID were forced to be kept in the transactional
cache and by consequence non-transactional changes that were supposed to
be flushed ahead of the transaction were kept in the transactional cache.

This happened because after BUG#51894 any statement whose thd's
thread_specific_used was set was kept in the transactional cache. The idea
was to keep changes on temporary tables in the transactional cache. However,
the thread_specific_used was set not only for statements that accessed
temporary tables but also when the CONNECTION_ID was used.

To fix the problem, we created a new variable to keep track of updates
to temporary tables.

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 check HAVE_OPENSSL in conjuction with EMBEDDED_LIBRARY.
More common fix would be to define a macros as HAVE_OPENSSL && !EMBEDDED_LIBRARY
and use it instead of HAVE_OPENSSL.

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