few small post-merge fixes

out of libmysql into separate dynamic plugins in the plugin/ directory.

move dialog and auth_socket plugins out of the plugin directory with examples into
dedicated directories in plugin/

* document safemalloc

client/mysql_upgrade.c:
  missing DBUG_RETURN
client/mysqladmin.cc:
  client plugin memory wasn't freed
client/mysqlcheck.c:
  client plugin memory, defaults, a result set, a command-line option value were not freed.
  missing DBUG_RETURN.
client/mysqldump.c:
  client plugin memory wasn't freed
client/mysqlslap.c:
  client plugin memory wasn't freed
client/mysqltest.cc:
  hopeless. cannot be fixed.
mysql-test/valgrind.supp:
  Bug#56666 is now fixed.
mysys/array.c:
  really, don't allocate if the caller didn't ask to.
mysys/my_init.c:
  safemalloc checks must be done at the very end
mysys/my_thr_init.c:
  not needed anymore
sql-common/client.c:
  memory leak
sql/log.cc:
  log_file was not closed, memory leak.
sql/mysqld.cc:
  fix bug#56666 (causing many P_S related memory leaks).
  close_active_mi() not called for --bootstrap, memory leak.
sql/sql_lex.cc:
  redo Lex->mi handling
sql/sql_lex.h:
  redo Lex->mi handling
sql/sql_plugin.cc:
  plugins having PLUGIN_VAR_MEMALLOC string variables have this variables allocated in every THD.
  The memory was freed in ~THD but only if plugin was still active. If plugin was unloaded the
  variable was not found and the memory was lost. By loading and unloading plugins an arbitrary
  amount of memory can be lost.
sql/sql_repl.cc:
  redo Lex->mi handling
sql/sql_yacc.yy:
  completely wrong handling of Lex->mi - run-time memory leak, by repeating the statement
  arbitrary amount of memory can be lost.
  
  Lex->mi.repl_ignore_server_ids_opt was allocated when parsing CHANGE MASTER,
  and freed after executing the statement. if parser failed on syntax (or another)
  error the statement was never executed. Lex->mi was simply bzero-ed for the next
  CHANGE MASTER  statement.
sql/table.cc:
  didn't compile
storage/perfschema/pfs_lock.h:
  Bug#56666 is fixed

... but differently

client/mysqltest.cc:
  my_safe_print_str() don't append \n anymore
dbug/dbug.c:
  restore safemalloc as a part of dbug suite
dbug/user.r:
  restore 'S' flag documentation
include/my_dbug.h:
  restore safemalloc as a part of dbug suite
include/my_sys.h:
  move valgrind defines to a dedicated header
mysys/my_malloc.c:
  use new safemalloc
mysys/stacktrace.c:
  don't append \n. let the calller do it, if needed
sql/mysqld.cc:
  my_safe_print_str() don't append \n anymore

very old halloca() support

(otherwise 10 ports per worker will be not enough)

Ensure that we do not hold the LOCK_open mutex while attempting
to establish FederatedX connection to guard against a trivial
Denial of Service scenario.

most tests pass.
5.3 merge is next

              UPDATED TWICE

For multi update it is not allowed to update a column
of a table if that table is accessed through multiple aliases
and either
1) the updated column is used as partitioning key
2) the updated column is part of the primary key 
   and the primary key is clustered

This check is done in unsafe_key_update().

The bug was that for case 2), it was checked whether
updated_column_number == table_share->primary_key 
However, the primary_key variable is the index number of the 
primary key, not a column number.

Prior to this bugfix, the first column was wrongly believed to be
the primary key. The columns covered by an index is found in
table->key_info[idx_number]->key_part. The bugfix is to check if
any of the columns in the keyparts of the primary key are
updated.

The user-visible effect is that for storage engines with
clustered primary key (e.g. InnoDB but not MyISAM) queries
like 
"UPDATE t1 AS A JOIN t2 AS B SET A.primkey=..."
will now error with 
"ERROR HY000: Primary key/partition key update is not allowed 
since the table is updated both as 'A' and 'B'." 
instead of 
"ERROR 1032 (HY000): Can't find record in 't1_tb'"
even if primkey is not the first column in the table. This 
was the intended behavior of bugfix 11764529.


mysql-test/r/multi_update.result:
  Add test for bug#11882110
mysql-test/r/multi_update_innodb.result:
  Add test for bug#11882110
mysql-test/t/multi_update.test:
  Add test for bug#11882110
mysql-test/t/multi_update_innodb.test:
  Add test for bug#11882110
sql/sql_update.cc:
  unsafe_key_update() wrongly checked if the primary key index
  number was the same as updated column number. Now it is checked
  whether any of the columns making up the primary key is updated.
sql/table.h:
  Fix comment on TABLE_SHARE::primary_key. Incorrect comment
  was introduced by an earlier merge conflict (as per dlenev)

can't parse relative paths "higher" than 3 levels up

When trying to LOAD DATA LOCAL INFILE using a relative path with 3 or
more levels up in the directory hierarchy, mysqld wrongly parses 
the path and as a consequence, can't find the file.

This bug was introduced by patch for bug#58205.
The reason for bug is that implementaiton of function cleanup_dirname()
doesn't take into account the begin of buffer being processed during
handling of path to file.


mysys/mf_pack.c:
  function cleanup_dirname() was modified: fixed wrong comparison
  condition when handling substring "../" at the begining of the buffer.

Some ut_a(!rec_offs_any_null_extern()) assertion failures are indicating
genuine BLOB bugs, others are bogus failures when rolling back incomplete
transactions at crash recovery. This needs more work, and until I get a
chance to work on it, other testing must not be disrupted by this.

revno 2995.37.209
revision id marko.makela@oracle.com-20110518120508-qhn7vz814vn77v5k
parent marko.makela@oracle.com-20110517121555-lmple24qzxqkzep4
timestamp: Wed 2011-05-18 15:05:08 +0300
message:
  Fix a bogus UNIV_SYNC_DEBUG failure in the fix of Bug #59641
  or Oracle Bug #11766513.

  trx_undo_free_prepared(): Do not acquire or release trx->rseg->mutex.
  This code is invoked in the single-threaded part of shutdown, therefore
  a mutex is not needed.

Issue:
When libmysqld/example/mysql_embedded is executed, it was getting abort. Its a
regression as it was working in 5.1 and failed in 5.5. Issue is there because 
remaining_argc/remaining_argv were not getting assigned correctly in 
init_embedded_server() which were being used later in init_common_variable().

Solution:
Rectified code to pass correct argc/argv to be used in init_common_variable().

libmysqld/lib_sql.cc:
  Rectified remaining_argc/remaining_argv assignment.
mysql-test/r/mysql_embedded.result:
  Result file for the test case added.
mysql-test/t/mysql_embedded.test:
  Added test case to verify libmysqld/example/mysql_embedded works.

               COLUMNS IN VIEWS

Issue:
charset value for a Column, returned by MYSQL_LIST_FIELDS(), was not same
for Table and View. This was because, for view, field charset was not being
returned.

Solution:
Added definition of function "charset_for_protocol()" in calss 
Item_ident_for_show to return field charset value.

sql/item.h:
  Added definition for charset_for_protocol() function to return field charset.
tests/mysql_client_test.c:
  Added a test case test_bug12337762 for the changes done.

This test case was failing on 5.5 and trunk for two reasons.
1) It waited for the "Waiting for table level lock" process
   state while this state was renamed "Waiting for table
   metadata lock" with the introduction of MDL in 5.5.
2) SET GLOBAL query_cache_size= 100000; gave a warning since
   query_cache_size is supposed to be multiples of 1024.

This patch fixes these two issues and re-enables the test case.

               RESULT CONSISTED OF MORE THAN ONE ROW

MySQL converts incorrect DATEs and DATETIMEs to '0000-00-00' on
insertion by default. This means that this sequence is possible:

CREATE TABLE t1(date_notnull DATE NOT NULL);
INSERT INTO t1 values (NULL);
SELECT * FROM t1;
0000-00-00

At the same time, ODBC drivers do not (or at least did not in the
90's) understand the DATE and DATETIME value '0000-00-00'. Thus,
to be able to query for the value 0000-00-00 it was decided in
MySQL 4.x (or maybe even before that) that for the special case
of DATE/DATETIME NOT NULL columns, the query "SELECT ... WHERE
date_notnull IS NULL" should return rows with date_notnull ==
'0000-00-00'. This is documented misbehavior that we do not want
to change.

The hack used to make MySQL return these rows is to convert 
"date_notnull IS NULL" to "date_notnull = 0". This is, however,
only done if the table date_notnull belongs to is not an inner
table of an outer join. The rationale for this seems to be that
if there is no join match for the row in the outer table,
null-complemented rows would otherwise not be returned because
the null-complemented DATE value is actually NULL. On the other
hand, this means that the "return rows with 0000-00-00 when the
query asks for IS NULL"-hack is not in effect for outer joins.

In this bug, we have a LEFT JOIN that does not misbehave like 
the documentation says it should. The fix is to rewrite

"date_notnull IS NULL" to "date_notnull IS NULL OR 
                           date_notnull = 0"
if dealing with an OUTER JOIN, otherwise 
"date_notnull IS NULL" to "date_notnull = 0"
as was done before.

Note:
The bug was originally reported as different result on first 
and second execution of SP. The reason was that during first
execution the query was correctly rewritten to an inner join
due to a null-rejecting predicate. On second execution the
"IS NULL" -> "= 0" rewrite was done because there was no outer
join. The real problem, though, was incorrect date/datetime 
IS NULL handling for OUTER JOINs.

mysql-test/r/type_datetime.result:
  Add test for BUG#12561818
mysql-test/t/type_datetime.test:
  Add test for BUG#12561818
sql/sql_select.cc:
  Special handling of NULL for DATE/DATETIME NOT NULL columns:
  In the case of outer join,
  "date_notnull IS NULL" 
  is now rewritten to
  "date_notnull IS NULL OR date_notnull = 0"

cmake/make_dist.cmake.in:
  Run 'bzr export' for plugins.
cmake/plugin.cmake:
  Lookup plugins with bzr repos.