Stored program cache produces wrong result in same THD.

confusing error. Updated the test script to work properly on
windows platform. 

Merge from 5.1 into 5.5.

Currently SHOW MASTER LOGS and SHOW BINARY LOGS require the SUPER
privilege. Monitoring tools (such as MEM) often want to check this 
output - for instance MEM generates the SUM of the sizes of the logs 
reported here, and puts that in the Replication overview within the MEM
Dashboard.
However, because of the SUPER requirement, these tools often have an 
account that holds open the connection whilst monitoring, and can lock
out administrators when the server gets overloaded and reaches
max_connections - there is already another SUPER privileged account
connected, the "monitor". 

As SHOW MASTER STATUS, and all other replication related statements,
return with either REPLICATION CLIENT or SUPER privileges, this worklog 
is to make SHOW MASTER LOGS and SHOW BINARY LOGS be consistent with this
as well, and allow both of these commands with either SUPER or 
REPLICATION CLIENT. 
This allows monitoring tools to not require a SUPER privilege any more,
so is safer in overloaded situations, as well as being more secure, as 
lighter privileges can be given to users of such tools or scripts.

                   ORDER BY COUNT(*) LIMIT.

PROBLEM:
With respect to problem in the bug description, we
exhibit different behaviors for the two tables
presented, because innodb statistics (rec_per_key
in this case) are updated for the first table
and not so for the second one. As a result the
query plan gets changed in test_if_skip_sort_order
to use 'index' scan. Hence the difference in the
explain output. (NOTE: We can reproduce the problem
with first table by reducing the number of tuples
and changing the table structure)

The varied output w.r.t the query on the second table
is because of the result in the query plan change.
When a query plan is changed to use 'index' scan,
after the call to test_if_skip_sort_order, we set
keyread to TRUE immedietly. If for some reason
we drop this index scan for a filesort later on,
we fetch only the keys not the entire tuple.
As a result we would see junk values in the result set.

Following is the code flow:

Call test_if_skip_sort_order
-Choose an index to give sorted output
-If this is a covering index, set_keyread to TRUE
-Set the scan to INDEX scan

Call test_if_skip_sort_order second time
-Index is not chosen (note that we do not pass the
actual limit value second time. Hence we do not choose
index scan second time which in itself is a bug fixed
in 5.6 with WL#5558)
-goto filesort

Call filesort
-Create quick range on a different index
-Since keyread is set to TRUE, we fetch only the columns of
the index
-results in the required columns are not fetched

FIX:
Remove the call to set_keyread(TRUE) from
test_if_skip_sort_order. The access function which is
'join_read_first' or 'join_read_last' calls set_keyread anyways.

confusing error. I have added the not_embedded.inc in the test file.

UNHANDLED, CONFUSING ERROR

The main confusion with the error message is that "it 
implies that your data dictionary may now be out of 
sync".  This patch will remove the unwanted and the 
misleading error message by not doing an unnecessary 
operation in the error handling code.  

rb://980 approved by: Dmitry Lenev

PROBLEM:

--------

When binary log statements are replayed on the slave, BEGIN is represented

in com_counters but COMMIT is not. Similarly in 'ROW' based replication

'INSERT','UPDATE',and 'DELETE' com_counters are not getting incremented

when the binary log statements are replayed at slave.

ANALYSIS:
---------

In 'ROW' based replication for COMMIT,INSERT,UPDATE and DELETE operations
following special events are invoked.
Xid_log_event,Write_rows_log_event,Update_rows_log_event,Update_rows_log_event.

The above mentioned events doesn't go through the parser where the
'COM_COUNTERS' are incremented.


FIX:
-----
Increment statements are added at appropriate events.
Respective functions are listed below.

'Xid_log_event::do_apply_event'
'Write_rows_log_event::do_before_row_operations'
'Update_rows_log_event::do_before_row_operations'
'Delete_rows_log_event::do_before_row_operations' 

                    TABLES IN INCORRECT ENGINE

PROBLEM:
  CREATE/ALTER TABLE currently can move system tables like
mysql.db, user, host etc, to engines other than MyISAM. This is not
completely supported as of now, by mysqld. When some of system tables
like plugin, servers, event, func, *_priv, time_zone* are moved
to innodb, mysqld restart crashes. Currently system tables
can be moved to BLACKHOLE also!!!.

ANALYSIS:
  The problem is that there is no check before creating or moving
a system table to some particular engine.

  System tables are suppose to be residing in MyISAM. We can think
of restricting system tables to exist only in MyISAM. But, there could
be future needs of these system tables to be part of other engines
by design. For eg, NDB cluster expects some tables to be on innodb
or ndb engine. This calls for a solution, by which system
tables can be supported by any desired engine, with minimal effort.

FIX:
  The solution provides a handlerton interface using which,
mysqld server can query particular storage engine handlerton for
system tables that it supports. This way each storage engine
layer can define their own system database and system tables.

  The check_engine() function uses the new handlerton function
ha_check_if_supported_system_table() to check if db.tablename
provided in the DDL is supported by the SE.

Note: This fix has modified a test in help.test, which was moving
mysql.help_* to innodb. The primary intention of the test was not
to move them between engines.

Problem - The cause of the failure is mainly due to the assert added in
          the code as a result of the fix of the BUG-13333431. When we
          start the server with the --skip-networking option enabled
          we have the mysqld_port explicitly to 0. Since the value of
          report_port is set to mysqld_port, the assertion that
          (report_port!= 0) fails.

Fix - the fix of the problem is to assert the not zero value of
      report_port only in the case the --skip-networking option is not
      used to start the mysqld server.

Problem - this failure occured in the test added for the fix of the 
          bug-13333431. The basic problem of the failure was the 
          value of the report_port which persisted even after the end 
          of the test (ie. rpl_end.inc). So this causes the assertion 
          in the test to fail if it is executed again.

Fix - restarted the server with the default value being passed to the 
      report_port after testing the two expected case so that in the 
      next run of the test we will not encounter the previous value of
      report_port.

This bug is a duplicate of Bug #31173, which was pushed to the 
mysql-trunk 5.6 on 4th Aug, 2010. This is just a back-port of 
the fix

This bug is a duplicate of Bug #31173, which was pushed to the 
mysql-trunk 5.6 on 4th Aug, 2010. This is just a back-port of 
the fix

Merge : 5.1->5.5

Background : 
In mysql-5.1, in a fix for bug#47485, code has been changed for 
mysql client (libmysql/libmysql.c) but corresponding code was not
changed for embedded mysql. In that code change, after execution
of a statement, mysql_stmt_store_result() checks for mysql->state
to be MYSQL_STATUS_STATEMENT_GET_RESULT, instead of
MYSQL_STATUS_GET_RESULT (earlier).

Reason:
In embedded mysql code, after execution, mysql->state was not
set to MYSQL_STATUS_STATEMENT_GET_RESULT, so it was throwing
OUT_OF_SYNC error.

Fix:
Fixed the code in libmysqld/lib_sql.cc to have mysql->state
to be set to MYSQL_STATUS_STATEMENT_GET_RESULT after execution.

                     IPV4/IPV6 ENABLED

Analysis:
----------------------
The problem was that if a hostname resolves to more than one IP-address,
the server (5.5) does not start due to an error. In 5.1 the server used to
take some IP-address and start.

It's a regression and should be fixed.

5.5 supports IPv6, while 5.1 does not. However, that should not 
prevent the server from start -- if a hostname has both IPv4 and IPv6 addresses,
the server should choose some IPv4-address and start.

It's been decided to prefer IPv4-address to be backward compatible with 5.1.

Another problem was that the 5.6 server did not report proper error message
when the specified hostname could not be resolved. So, the code has been 
changed to report proper error message.

Testing
================================
5.5
=============================
invalid hostname (localhos):
  => Following error message reported.
     120308 15:52:09 [ERROR] Can't start server: cannot resolve hostname!
     120308 15:52:09 [ERROR] Aborting

invalid ip_address:
  => Following error message reported.
      120308 15:56:06 [Note] Server hostname (bind-address): '123.123.123.123'; port: 3306
      120308 15:56:06 [Note]   - '123.123.123.123' resolves to '123.123.123.123';
      120308 15:56:06 [Note] Server socket created on IP: '123.123.123.123'.
      120308 15:56:06 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address

Only ipv4 host configured:
  => Following message logged 
    120308 16:02:50 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:02:50 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:02:50 [Note] Server socket created on IP: '127.0.0.1'

Only ipv6 host configured:    
  => Following message logged 
    120308 16:04:03 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:04:03 [Note]   - 'localhost' resolves to '::1';
    120308 16:04:03 [Note] Server socket created on IP: '::1'.

ipv4 and ipv6 host configured:
  => Following message logged
    120308 16:05:02 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:05:02 [Note]   - 'localhost' resolves to '::1';
    120308 16:05:02 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:05:02 [Note] Server socket created on IP: '127.0.0.1'.
  => Non localhost address  
    120308 16:08:20 [Note] Server hostname (bind-address): 'mysql_addr'; port: 3306
    120308 16:08:20 [Note]   - 'mysql_addr' resolves to '10.178.58.216';
    120308 16:08:20 [Note]   - 'mysql_addr' resolves to 'fe80::120b:a9ff:fe69:59ec';
    120308 16:08:20 [Note] Server socket created on IP: '10.178.58.216'.

More than one entry for ipv4 and ipv6 address:
  => Following message logged
    120308 16:06:19 [Note] Server hostname (bind-address): 'localhost'; port: 3306
    120308 16:06:19 [Note]   - 'localhost' resolves to '::1';
    120308 16:06:19 [Note]   - 'localhost' resolves to '::1';
    120308 16:06:19 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:06:19 [Note]   - 'localhost' resolves to '127.0.0.1';
    120308 16:06:19 [Note] Server socket created on IP: '127.0.0.1'.

rev_id: inaam.rana@oracle.com-20120326134501-23554a8vhjg0wqbm

      
 Description: When the table has more than one unique or primary key, 
 INSERT... ON DUP KEY UPDATE statement is sensitive to the order in which
 the storage engines checks the keys. Depending on this order, the storage
 engine may determine different rows to mysql, and hence mysql can update
 different rows on master and slave.
      
 Solution: We mark INSERT...ON DUP KEY UPDATE on a table with more than on unique
 key as unsafe therefore the event will be logged in row format if it is available
 (ROW/MIXED). If only STATEMENT format is available, a warning will be thrown. 

Background:

  - as described in MySQL Internals Prepared Stored
    (http://forge.mysql.com/wiki/MySQL_Internals_Prepared_Stored),
    the Optimizer sometimes does destructive changes to the parsed
    LEX-object (Item-tree), which makes it impossible to re-use
    that tree for PS/SP re-execution.

  - in order to be able to re-use the Item-tree, the destructive
    changes are remembered and rolled back after the statement execution.

The problem, discovered by this bug, was that the objects representing
GROUP-BY clause did not restored after query execution. So, the GROUP-BY
part of the statement could not be properly re-initialized for re-execution
after destructive changes.

Those objects do not take part in the Item-tree, so they can not be saved
using the approach for Item-tree.

The fix is as follows:

  - introduce a new array in st_select_lex to store the original
    ORDER pointers, representing the GROUP-BY clause;

  - Initialize this array in fix_prepare_information().

  - restore the list of GROUP-BY items in reinit_stmt_before_use().

        
Fix the calculation of the next autoinc value when offset > 1. Some of the
results have changed due to the changes in the allocation calculation. The
new calculation will result in slightly bigger gaps for bulk inserts.
  
rb://866 Approved by Jimmy Yang.
Backported from mysql-trunk (5.6)

LOCK_THREAD_COUNT

When using the performance schema file io instrumentation in MySQL 5.5,
a thread would loop forever inside lf_pinbox_put_pins, when disconnecting.
It would also hold LOCK_thread_count while doing so, effectively killing the
server.

The root cause of the loop in lf_pinbox_put_pins() is a leak of LF_PINS,
when used with the filename_hash LF_HASH table in the performance schema.

This fix contains the following changes:

1)
Added the missing call to lf_hash_search_unpin(), to prevent the leak.

2)
In mysys/lf_alloc-pin.c, there was some extra debugging code
(MY_LF_EXTRA_DEBUG) written to detect precisely this kind of issues,
but it was never used.
Replaced MY_LF_EXTRA_DEBUG with DBUG_OFF, so that leaks similar to this one
can be always detected in regular debug builds.

3)
Backported the fix for the following bug, from 5.6 to 5.5:
Bug#13417446 - 63339: INCORRECT FILE PATH IN PEFORMANCE_SCHEMA ON WINDOWS

Analysis:
-------------------------------
According to the Manual
(http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
"Column, index, stored routine, and event names are not case sensitive on any
platform, nor are column aliases."

In other words, 'lower_case_table_names' does not affect the behaviour of 
those identifiers.

On the other hand, trigger names are case sensitive on some platforms,
and case insensitive on others. 'lower_case_table_names' does not affect
the behaviour of trigger names either.

The bug was that SHOW statements did case sensitive comparison
for stored procedure / stored function / event names.

Fix:
Modified the code so that comparison in case insensitive for routines 
and events for "SHOW" operation.

As part of this commit, only fixing the test failures due to the actual code fix.

Change the type of purge_sys_t::n_pages_handled and purge_sys_t::handle_limit
to ulonglong from ulint. On a 32 bit system doing ~700 deletes per second the
counters can overflow in ~3.5 months, if they are 32 bit.

Approved by Jimmy Yang over IM.

Analysis:
-------------------------------
According to the Manual
(http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
"Column, index, stored routine, and event names are not case sensitive on any
platform, nor are column aliases."

In other words, 'lower_case_table_names' does not affect the behaviour of 
those identifiers.

On the other hand, trigger names are case sensitive on some platforms,
and case insensitive on others. 'lower_case_table_names' does not affect
the behaviour of trigger names either.

The bug was that SHOW statements did case sensitive comparison
for stored procedure / stored function / event names.

Fix:
Modified the code so that comparison in case insensitive for routines 
and events for "SHOW" operation.

rb://942
approved by: Marko Makela

We don't need to scan LRU for dropping AHI entries when DROPing a table.
AHI entries are already removed when we free up extents for the btree.