TABLE/KEY RELATIONS

Problem:

When there are many tables, linked together through the foreign key
constraints, then loading one table will recursively open other tables.  This
can sometimes lead to thread stack overflow.  In such situations the server
will exit.

I see the stack overflow problem when the thread_stack is 196608 (the default
value for 32-bit systems).  I don't see the problem when the thread_stack is
set to 262144 (the default value for 64-bit systems).

Solution:

Currently, in InnoDB, there is a macro DICT_FK_MAX_RECURSIVE_LOAD which defines
the maximum number of tables that will be loaded recursively because of foreign
key relations.  This is currently set to 250.  We can reduce this number to 33
(anything more than 33 does not solve the problem for the default value).  We
can keep it small enough so that thread stack overflow does not happen for the
default values.  Reducing the DICT_FK_MAX_RECURSIVE_LOAD will not affect the
functionality of InnoDB.  The tables will eventually be loaded. 

rb#2058 approved by Marko

The GIS WKB reader was checking for the presence of
enough data by first multiplying the number read (where
it could overflow) and only then comparing it to the
number of bytes available.
This can overflow and effectively turn off the check.
Fixed by:
1. Introducing a new function that does division only so
no overflow is possible.
2. Using the proper macros and parenthesizing them.
3. Doing an in-line division check in the only place where
the boundary check is done over a data structure other
than a dense points array.

Merge from mysql-5.1 into mysql-5.5.

Fixed possible uninitialized variable.

--BINLOG-IGNORE-DB AND FULLY QUALIFIED TABLE
      
Problem:
=======
An ALTER TABLE statement is not written to binlog if server
started with "--binlog-ignore-db some database" and 'fully
qualified' table names are used in the ALTER TABLE statement
altering table different from current database context.
      
Analysis:
========
The above mentioned problem not only affects "ALTER TABLE"
statements but also to all kind of statements. Once the 
current default database becomes "NULL" none of the 
statements will be binlogged.
      
The current behaviour is such that if the user has specified
restrictions on which database needs to be replicated and the
default db is not specified, then do not replicate.
This means that "NULL" is considered to be equivalent to
everything (default db = null implied ignore don't log the
statement).
      
Fix:
===
"NULL" should not be considered as equivalent to everything.
Since the filtering criteria is not equal to "NULL" the
statement should be logged into binlog.

mysql-test/suite/rpl/r/rpl_loaddata_m.result:
  Earlier when defalut database was "NULL" DROP TABLE
  was not getting logged. Post this fix it will be logged
  and the DROP will fail at slave as the table creation
  was skipped by master as --binlog-ignore-db=test.
mysql-test/suite/rpl/t/rpl_loaddata_m.test:
  Earlier when defalut database was "NULL" DROP TABLE
  was not getting logged. Post this fix it will be logged
  and the DROP will fail at slave as the table creation
  was skipped by master as --binlog-ignore-db=test.
sql/rpl_filter.cc:
  Replaced DBUG_RETURN(0) with DBUG_RETURN(1).

TABLE/KEY RELATIONS

Problem:

When there are many tables, linked together through the foreign key
constraints, then loading one table will recursively open other tables.  This
can sometimes lead to thread stack overflow.  In such situations the server
will exit.

I see the stack overflow problem when the thread_stack is 196608 (the default
value for 32-bit systems).  I don't see the problem when the thread_stack is
set to 262144 (the default value for 64-bit systems).

Solution:

Currently, in InnoDB, there is a macro DICT_FK_MAX_RECURSIVE_LOAD which defines
the maximum number of tables that will be loaded recursively because of foreign
key relations.  This is currently set to 250.  We can reduce this number to 33
(anything more than 33 does not solve the problem for the default value).  We
can keep it small enough so that thread stack overflow does not happen for the
default values.  Reducing the DICT_FK_MAX_RECURSIVE_LOAD will not affect the
functionality of InnoDB.  The tables will eventually be loaded. 

rb#2058 approved by Marko

No commit message

At logging a first Query referring a user var, the slave missed to log the user var.
It appears that at execution of a Uservar event the slaver applier
thought of the variable as already logged.
The reason of misjudgement is in coincidence of query id:s: of one that the thread
holds at Uservar execution and another one that the thread sees at the Query applying.
While the two are naturally different in the regular execution branch (as two computational
events are separated as individual events), in the deferred applying case the User var execution
effectively belongs to its Query processing.

Fixed with storing the Uservar parsing time (where desicion to defer is taken) query id 
to temporarily substitute with it the actual query id at the Uservar execution time
(along with its query).
Such manipulation mimics behaviour of the regular applying branch.

sql/log_event.cc:
  Storing the Uservar parsing time query id into a new member of the event
  to to temporarily substitute
  with it the actual thread id at the Uservar execution time.
sql/log_event.h:
  Storage for keeping query-id in User-var intance is added.

Bug#13243248 CHECK FOR "STACK OVERRUN" DOESN'T WORK WITH GCC-4.6, SERVER CRASHES

The existing check for stack direction may give wrong results
for new versions of gcc at high optimization levels.

Solution: Backport the stack-direction check from 5.5

      
Problem - When the slave was disconnected from the master, under certain 
          conditions, upon reconnect, it will report that it received a 
          packet larger the slave_max_allowed_packet which causes the
          replication to stop.
 
Analysis -The reason of this failure is that on reconnect
          the slave sets the max_allowed_packet from the master's mi->mysql
          object which keeps the max_allowed_packet as 1MB. This causes the 
          slave to report such error on recieving packet bigger than 1MB. 
          START SLAVE on the slave fixes the problem since it restarts
          slave threads which initializes the max_allowed_packet to
          slave_max_allowed_packet.
      
Fix - The problem is fixed by some code refactoring and introduction of a new
      function which updates the max_allowed_packet for the THD object of the
      slave thread and the mysql->options max_allowed_packet.

As current size limit of 'url' field of help_topic
table is no longer sufficient for the contents of
the fill_help_tables-5.1.sql. So, loading the contents
in the table might result in warning (or error with
stricter modes).

Updated the type for 'url' field of help_topic as well
as help_category tables from char(128) to text.

(Based on Sinisa's patch)

Added a version checking facility to mysql_upgrade.
The versions used for checking is the version of the
server that mysql_upgrade is going to upgrade and the
server version that mysql_upgrade was build/distributed
with.
Also added an option '--version-check' to enable/disable
the version checking.

SHOW ENGINE INNOD

Problem:

The purpose of explain_filename() is to provide useful additional
information regarding the partitions given the filename.  This function
was returning an error when it was not able to parse the given filename.
For example, within InnoDB, temporary files are created with #sql-
prefix.  But this function was not able to parse it correctly.

Solution:

It is not an error, if explain_filename() could not parse the given
filename.  If there is no partition information to explain, then silently
return from the function.

rb#1940 approved by mattiasj

The range optimizer uses 'save_in_field_no_warnings()' to verify properties of
'value <cmp> field' expressions.
If this execution yields an error, it should abort.

              RETURNS RANDOM DATA
                 
MySQL 5.5 specific version of bugfix.
      
When Loose Index Scan Range access is used, MySQL execution needs
to copy non-aggregated fields. end_send() checked if this was
necessary by checking if join_tab->select->quick had type
QS_TYPE_GROUP_MIN_MAX.
      
In this bug, however, MySQL created a sort index to sort the rows
read from this range access method. create_sort_index() deletes
join_tab->select->quick which makes it impossible to inquire
the join_tab if LIS has been used.
      
The fix for MySQL 5.5 is to introduce a variable in JOIN_TAB
that stores whether or not LIS has been used. There is no need
for this variable in later MySQL versions because the relevant
code has been refactored.

Post push fix:
setup_ref_array() now uses n_sum_items to determine size of ref_pointer_array.
The problem was that n_sum_items kept growing, it wasn't reset for each query.

A similar memory leak was fixed with the patch for:
Bug 14683676 ENDLESS MEMORY CONSUMPTION IN SETUP_REF_ARRAY WITH MAX IN SUBQUERY


sql/sql_yacc.yy:
  Reset parsing_place when we're done parsing SHOW commands, 
  to prevent Item::Item incrementing select_n_having_items
  (which is also used in setup_ref_array())

UPDATES

After checking that the table has changed too much in
row_update_statistics_if_needed() and calling dict_update_statistics(),
also check if the same condition holds after acquiring the table stats
latch. This is to avoid multiple threads concurrently entering and
executing the stats update code.

Approved by:	Marko (rb:2186)