Bug#35996: SELECT + SHOW VIEW should be enough to display
view definition

During SHOW CREATE VIEW there is no reason to 'anonymize'
errors that name objects that a user does not have access
to. Moreover it was inconsistently implemented. For example
base tables being referenced from a view appear to be ok,
but not views. The manual on the other hand is clear: If a
user has the privileges SELECT and SHOW VIEW, the view
definition is available to that user, period. The fix
changes the behavior to support the manual.


mysql-test/r/information_schema_db.result:
  Bug#35996: Changed warnings.
mysql-test/r/view_grant.result:
  Bug#35996: Changed warnings, test result.
mysql-test/t/information_schema_db.test:
  Bug#35996: Changed test case to reflect new behavior.
mysql-test/t/view_grant.test:
  Bug#35996: Test case.
sql/sql_acl.cc:
  Bug#35996: Code no longer necessary, we may as well exempt 
  SHOW CREATE VIEW from this check.
sql/sql_show.cc:
  Bug#35996: The fix: An Internal_error_handler that hides
  most errors raised by access checking as they are not
  relevant to SHOW CREATE VIEW.
sql/table.cc:
  Bug#35996: Restricting this hack to act only when there is 
  no Internal_error_handler.

All statements executed by mysql_upgrade are binlogged and then are replicated to slave.
This will result in some errors. The report of this bug has demonstrated some examples.

Master and slave should be upgraded separately. All statements executed by
mysql_upgrade will not be binlogged. 
--write-binlog and --skip-write-binlog options are added into mysql_upgrade. 
These options control whether sql statements are binlogged or not. 

      
In RBR, 'DROP TEMPORARY TABLE IF EXISTS...' statement is binlogged when the table
does not exist.
      
In fact, 'DROP TEMPORARY TABLE ...' statement should never be binlogged in RBR
no matter if the table exists or not. 
This patch addresses this by checking whether we are dropping a
temporary table or not, when building the custom drop statement.

HA_ERR_WRONG_INDEX
      
In RBR, disabling keys on slave table will break replication when
updating or deleting a record. When the slave thread tries to
find the row, by searching in the storage engine, it checks
whether the table has a key or not. If it has one, then the slave
thread uses it to search the record.
      
Nonetheless, the slave only checks whether the key exists or not,
it does not verify if it is active. Should the key be
disabled (eg, DBA has issued an ALTER TABLE ... DISABLE KEYS)
then it will result in error: HA_ERR_WRONG_INDEX.
      
This patch addresses this issue by making the slave thread also
check whether the key is active or not before actually using it.

The failure is not reproduced on 5.1, so enable the 'rpl_cross_version' test.

mysql-test/suite/rpl/t/disabled.def:
  Got rid of the line for enabling 'rpl_cross_version' test.

Network error happened here, but it can be caused by CR_CONNECTION_ERROR, 
CR_CONN_HOST_ERROR, CR_SERVER_GONE_ERROR, CR_SERVER_LOST, ER_CON_COUNT_ERROR, 
and ER_SERVER_SHUTDOWN. We just check CR_SERVER_LOST here, so the test fails.

To fix the problem, check all errors that can be cause by the master shutdown.

mysql-test/extra/rpl_tests/rpl_get_master_version_and_clock.test:
  Added a 'if' sentence to check all errors that can be cause by the master shutdown.
mysql-test/suite/rpl/r/rpl_get_master_version_and_clock.result:
  Test result is updated duo to the patch of bug#46931

from test-extra tree.

Changes include improvements to error handling and are based on WL#4685

with gcc 4.3.2

Cleaning up warnings not present in 5.0.

when compiled with Sun Studio compiler).

The thing is that Sun Studio compiler calls destructor of stack
objects when pthread_exit() is called. That triggered an assertion
in DBUG_ENTER()/DBUG_RETURN() validation logic (if DBUG_ENTER() is
used in the beginning of function, all returns should be replaced
by DBUG_RETURN/DBUG_VOID_RETURN macros).

A fix is to explicitly use DBUG_LEAVE macro.

                               value from the index (PRIMARY)


With the fix for BUG#46760, we correctly flag the presence of row_type 
only when it's actually changed and enables the FAST ALTER TABLE which was
disabled with the BUG#39200.

So the changes made by BUG#46760 makes MySQL data dictionaries to be out of 
sync but they are handled already by InnoDB with this BUG#44030.

The test was originally written to handle this but we requested Innodb to
update the test as the data dictionaries were in sync after the fix for 
BUG#39200.

Adjusting the innodb-autoinc testcase as mentioned in the comments.

mysql-test/lib/mtr_cases.pm:
  Re-enable the innodb-autoinc test case for plugin as we have a common
  result file.
mysql-test/r/innodb-autoinc.result:
  Additional Fix for BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc 
                                 value from the index (PRIMARY)
  
  Adjust the innodb-autoinc testcase as the patch for BUG#46760 enables the 
  FAST ALTER TABLE and makes the data dictonaries go out of sync. This is 
  expected in the testcase.
mysql-test/t/innodb-autoinc.test:
  Additional Fix for BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc 
                                 value from the index (PRIMARY)
  
  Adjust the innodb-autoinc testcase as the patch for BUG#46760 enables the 
  FAST ALTER TABLE and makes the data dictonaries go out of sync. This is 
  expected in the testcase.

the fix is reverted from 5.1, mysql-pe as 
unnecessary(no valgrind warnings there).

sql/sql_select.cc:
  the fix is reverted from 5.1, mysql-pe as 
  unnecessary(no valgrind warnings there).

The "socket" variable is not available on Windows even though
the --socket option can be used to specify the pipe name for
local connections that use a named pipe.

The solution is to ensure that the variable is always defined.


mysql-test/r/windows.result:
  Add test case result for Bug#45498
mysql-test/t/windows.test:
  Add test case for Bug#45498
sql/set_var.cc:
  socket variable must always be present.

checksum)"

The problem was that checksum of GEOMETRY type used memory addresses
in the computation, making it un-repeatable thus useless.
(This patch is a backport from 6.0 branch)

mysql-test/r/myisam.result:
  test case for bug35570 that same tables give same checksums
mysql-test/t/myisam.test:
  test case for bug35570 that same tables give same checksums
sql/sql_table.cc:
  Type GEOMETRY is implemented on top of type BLOB, so, just like for BLOB,
  its 'field' contains pointers which it does not make sense to include in
  the checksum; it rather has to be converted to a string and then we can
  compute the checksum.

      
Despite copying the value of the old table's row type
we don't always have to mark row type as being specified.
Innodb uses this to check if it can do fast ALTER TABLE
or not.
Fixed by correctly flagging the presence of row_type 
only when it's actually changed.
Added a test case for 39200.

           But there is no Last_IO_Error reported.

On the master, if a binary log event is larger than max_allowed_packet,
ER_MASTER_FATAL_ERROR_READING_BINLOG and the specific reason of this error is
sent to a slave when it requests a dump from the master, thus leading
the I/O thread to stop.

On a slave, the I/O thread stops when receiving a packet larger than max_allowed_packet.

In both cases, however, there was no Last_IO_Error reported.

This patch adds code to report the Last_IO_Error and exact reason before stopping the
I/O thread and also reports the case the out memory pops up while
handling packets from the master.


sql/sql_repl.cc:
  The master send the Specific reasons instead of "error reading log entry" to the slave which is requesting a dump.
  if an fatal error is returned by read_log_event function.

Large pages allocator could not allocate more than 4 GB due to
incorrect size alignment.

mysys/my_largepage.c:
  Large pages allocator could not allocate more than 4 GB due to
  incorrect size alignment.

with gcc 4.3.2
      
This is the fifth patch cleaning up more GCC warnings about
variables used before initialized using the new macro
UNINIT_VAR().

 "insert into.. select * from"

When inserting into a partitioned table using 'insert into
<target> select * from <src>', read_buffer_size bytes of memory
are allocated for each partition in the target table.

This resulted in large memory consumption when the number of
partitions are high.

This patch introduces a new method which tries to estimate the
buffer size required for each partition and limits the maximum
buffer size used to maximum of 10 * read_buffer_size, 
11 * read_buffer_size in case of monotonic partition functions.

sql/ha_partition.cc:
  Introduced a method ha_partition::estimate_read_buffer_size
  to estimate buffer size required for each partition. 
  Method ha_partition::start_part_bulk_insert updated
  to update the read_buffer_size before calling bulk upload
  in storage engines.
  Added thd in ha_partition::start_part_bulk_insert method signature.
sql/ha_partition.h:
  Introduced a method ha_partition::estimate_read_buffer_size.
  Added thd in ha_partition::start_part_bulk_insert method signature.