Bug#25422 (Hang with log tables)
Bug 17876 (Truncating mysql.slow_log in a SP after using cursor locks the
          thread)
Bug 23044 (Warnings on flush of a log table)
Bug 29129 (Resetting general_log while the GLOBAL READ LOCK is set causes
           a deadlock)

Prior to this fix, the server would hang when performing concurrent
ALTER TABLE or TRUNCATE TABLE statements against the LOG TABLES,
which are mysql.general_log and mysql.slow_log.

The root cause traces to the following code:
in sql_base.cc, open_table()
  if (table->in_use != thd)
  {
    /* wait_for_condition will unlock LOCK_open for us */
    wait_for_condition(thd, &LOCK_open, &COND_refresh);
  }
The problem with this code is that the current implementation of the
LOGGER creates 'fake' THD objects, like
- Log_to_csv_event_handler::general_log_thd
- Log_to_csv_event_handler::slow_log_thd
which are not associated to a real thread running in the server,
so that waiting for these non-existing threads to release table locks
cause the dead lock.

In general, the design of Log_to_csv_event_handler does not fit into the
general architecture of the server, so that the concept of general_log_thd
and slow_log_thd has to be abandoned:
- this implementation does not work with table locking
- it will not work with commands like SHOW PROCESSLIST
- having the log tables always opened does not integrate well with DDL
operations / FLUSH TABLES / SET GLOBAL READ_ONLY

With this patch, the fundamental design of the LOGGER has been changed to:
- always open and close a log table when writing a log
- remove totally the usage of fake THD objects
- clarify how locking of log tables is implemented in general.

See WL#3984 for details related to the new locking design.

Additional changes (misc bugs exposed and fixed):

1)

mysqldump which would ignore some tables in dump_all_tables_in_db(),
 but forget to ignore the same in dump_all_views_in_db().

2)

mysqldump would also issue an empty "LOCK TABLE" command when all the tables
to lock are to be ignored (numrows == 0), instead of not issuing the query.

3)

Internal errors handlers could intercept errors but not warnings
(see sql_error.cc).

4)

Implementing a nested call to open tables, for the performance schema tables,
exposed an existing bug in remove_table_from_cache(), which would perform:
  in_use->some_tables_deleted=1;
against another thread, without any consideration about thread locking.
This call inside remove_table_from_cache() was not required anyway,
since calling mysql_lock_abort() takes care of aborting -- cleanly -- threads
that might hold a lock on a table.
This line (in_use->some_tables_deleted=1) has been removed.

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  moonbone.local:/mnt/gentoo64/work/29898-bug-5.0-opt-mysql

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

The Item_date_typecast::val_int function doesn't reset null_value flag.
This makes all values that follows the first null value to be treated as nulls
and led to a wrong result.

Now the Item_date_typecast::val_int function correctly sets the null_value flag
for both null and non-null values.

into  moonbone.local:/mnt/gentoo64/work/29850-bug-5.0-opt-mysql

crash" in 5.1

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

a temporary table.

The result string of the Item_func_group_concat wasn't initialized in the 
copying constructor of the Item_func_group_concat class. This led to a
wrong charset of GROUP_CONCAT result when the select employs a temporary
table.

The copying constructor of the Item_func_group_concat class now correctly
initializes the charset of the result string.

into  mysql.com:/home/hf/work/29687/my51-29687

into  mysql.com:/home/hf/work/29687/my51-29687

into  mysql.com:/home/hf/work/29687/my50-29687

into  mysql.com:/home/hf/work/29687/my50-29687

into  mysql.com:/home/hf/work/29687/my51-29687

into  bk-internal.mysql.com:/data0/bk/tsmith-tmp/mysql-5.1-maint

into  bk-internal.mysql.com:/data0/bk/tsmith-tmp/mysql-5.0-maint

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

for consistency.

No test case, since the bug requires a stress case with 30 INSERT DELAYED
threads and 1 killer thread to repeat. The patch is verified
manually.
Review fixes.

The server that is running DELAYED inserts would deadlock itself
or crash under high load if some of the delayed threads were KILLed
in the meanwhile.

The fix is to change internal lock acquisition order of delayed inserts
subsystem and to ensure that
Delayed_insert::table_list::db does not point to volatile memory in some 
cases.
For details, please see a comment for sql_insert.cc.

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

  Post-merge fix.

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/51

  Don't run test with embedded server; requires external client connections

function doesn't set it to something else.