Problem: "COM_FIELD_LIST is an old command of the MySQL server, before there was real move to only
SQL. Seems that the data sent to COM_FIELD_LIST( mysql_list_fields() function) is not
checked for sanity. By sending long data for the table a buffer is overflown, which can
be used deliberately to include code that harms".

Fix: check incoming data length.


sql/sql_parse.cc:
  Fix for bug #53237: mysql_list_fields/COM_FIELD_LIST stack smashing
    - check incoming mysql_list_fields() table name arg length.

during an UPDATE

Extended the fix for bug 29310 to multi-table update:

When a table is being updated it has two set of fields - fields required for
checks of conditions and fields to be updated. A storage engine is allowed
not to retrieve columns marked for update. Due to this fact records can't
be compared to see whether the data has been changed or not. This makes the
server always update records independently of data change.
  
Now when an auto-updatable timestamp field is present and server sees that
a table handle isn't going to retrieve write-only fields then all of such
fields are marked as to be read to force the handler to retrieve them.

The problem is that message resource  (message.rc) is compiled as part of static library
sql.lib rather than with executable mysqld.exe. resource files do not work in static
libraries.

The fix is to add message.rc to mysqld.exe source files list.

The problem was in an incorrect debug assertion. The expression
used in the failing assertion states that when finding
references matching ORDER BY expressions, there can be only one
reference to a single table. But that does not make any sense,
all test cases for this bug are valid examples with multiple
identical WHERE expressions referencing the same table which
are also present in the ORDER BY list.

Fixed by removing the failing assertion. We also have to take
care of the 'found' counter so that we count multiple
references only once. We rely on this fact later in
eq_ref_table().

mysql-test/r/join.result:
  Added a test case for bug #50335.
mysql-test/t/join.test:
  Added a test case for bug #50335.
sql/sql_select.cc:
  Removing the assertion in eq_ref_table() as it does not make
  any sense. We also have to take care of the 'found' counter so
  that we count multiple references only once. We rely on this
  fact later in eq_ref_table().

Problem: ALTER TABLE ADD INDEX may lead to table copying if there's
numeric field(s) with non-default display width modificator specified.

Fix: compare numeric field's storage lenghts when we decide whether 
they can be considered 'equal' for table alteration purposes.


mysql-test/r/error_simulation.result:
  Fix for bug#50946: fast index creation still seems to copy the table
    - test result.
mysql-test/t/error_simulation.test:
  Fix for bug#50946: fast index creation still seems to copy the table
    - test case.
sql/field.cc:
  Fix for bug#50946: fast index creation still seems to copy the table
    - check numeric field's pack lengths instead of it's display lenghts
  comparing fields equality for table alteration purposes.
sql/sql_table.cc:
  Fix for bug#50946: fast index creation still seems to copy the table
    - check compare_tables() result for testing purposes.

Previously installed dynamic plugins are explicitly not loaded
on startup with --skip-grant-tables enabled. However, INSTALL
PLUGIN/UNINSTALL PLUGIN commands are allowed, and result in
inconsistent error messages (reporting duplicate plugin or
plugin does not exist).

This patch adds a check for --skip-grant-tables mode, and
returns error ER_OPTION_PREVENTS_STATEMENT to the user when
the above commands are attempted.

Correcting a patch misstake. The converted file path is placed in 'buff' not in opt_secure_file_priv.

mysql-test/r/loaddata.result:
  * Updated test case; Since secure_file_priv now is normalized the previous values are changed.
sql/mysqld.cc:
  * Fixed patch misstake

Unlocking/locking of LOCK_plugin in ha_ndbcluster.cc not 
needed anymore (but missing from the initial patch).

The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the 
--secure-file-priv option.

The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.

It was also intended that setting the option
to an empty string should be equal to 
lifting all previously set restrictions. This
is also fixed by this patch.


sql/mysqld.cc:
  * If --secure_file_option is an empty string then the option variable
    should be unset.
  * opt_secure_file_option should be normalized once when the server starts.
sql/sql_load.cc:
  * moved variable normalization code to fix_paths()

      
Potential deadlock situation involving LOCK_plugin,
LOCK_global_system_variables and LOCK_status.
      
This patch backports the fix from next-mr, unlocking
LOCK_plugin before calling plugin->init() and
add_status_vars().

Arg_comparator initializes 'comparators' array in case of
ROW comparison and does not free this array on destruction.
It leads to memory leaks.
The fix:
-added Arg_comparator::cleanup() method which frees
 'comparators' array.
-added Item_bool_func2::cleanup() method which calls 
 Arg_comparator::cleanup() method


mysql-test/r/ps.result:
  test case
mysql-test/r/row.result:
  test case
mysql-test/t/ps.test:
  test case
mysql-test/t/row.test:
  test case
sql/item_cmpfunc.h:
  -added Arg_comparator::cleanup() method which frees
   'comparators' array.
  -added Item_bool_func2::cleanup() method which calls 
   Arg_comparator::cleanup() method

When re-setting (SET GLOBAL debug='') the GLOBAL debug settings the 
server was not freeing the data elements from the top (initial) frame 
before setting them to 0 without freeing the underlying memory. As these 
are global settings there's a chance that something is there already.
Fixed by :
1. making sure the allocated data are cleaned up before re-setting them
while parsing a debug string
2. making sure the stuff allocated in the global settings is freed on 
shutdown.

            to cleanup open connections

It was possible to UNINSTALL storage engine plugin when binding
between THD object and storage engine is still active (e.g. in
the middle of transaction).

To avoid unclean deactivation (uninstall) of storage engine plugin
in the middle of transaction, additional storage engine plugin
lock is acquired by thd_set_ha_data().

If ha_data is not null and storage engine plugin was not locked
by thd_set_ha_data() in this connection before, storage engine
plugin gets locked.

If ha_data is null and storage engine plugin was locked by
thd_set_ha_data() in this connection before, storage engine
plugin lock gets released.

If handlerton::close_connection() didn't reset ha_data, server does
it immediately after calling handlerton::close_connection().

Note that this is just a framework fix, storage engines must switch
to thd_set_ha_data() from thd_ha_data() if they want to see fit.

include/mysql/plugin.h:
  As thd_{get|set}_ha_data() have some extra logic now, they
  must be implemented on server side.
include/mysql/plugin.h.pp:
  As thd_{get|set}_ha_data() have some extra logic now, they
  must be implemented on server side.
sql/handler.cc:
  Make sure ha_data is reset and ha_data lock is released.
sql/handler.h:
  hton is not supposed to be updated by ha_lock_engine(),
  make it const.
sql/sql_class.cc:
  As thd_{get|set}_ha_data() have some extra logic now, they
  must be implemented on server side.
sql/sql_class.h:
  Added ha_data lock.

Added a filter to mysqlhotcopy to filter out the same tables in the 'mysql' 
database that mysqldump filters out.

Add ignore pattern for valgrind messages.

Several problems addressed:

1. The maximum value for --open_files_limit on non-windows boxes
is now raised to UINT_MAX (the maximum possible without significant
changes in the code). The maximum value on windows is kept to be
2048 due to a known limitation (bug 24509).

2. mysqld_safe now supports --open_files_limit=xx in addition to 
--open-files-limit=xx

3. mysqld_safe always passes through --open[_-]files[_-]limit
to the underlying mysqld. It used to pass it through only if it 
the user running the script has access to the root directory or
there was an --user argument specified.

4. Fixed a prototype in my_file.c to match its counterpart in 
the other #ifdef branch.

mistake in previous push

We should disable const subselect item evaluation because
subselect transformation does not happen in view_prepare_mode
and thus val_...() methods can not be called.


mysql-test/r/ctype_ucs.result:
  test case
mysql-test/r/view.result:
  test case
mysql-test/t/ctype_ucs.test:
  test case
mysql-test/t/view.test:
  test case
sql/item.cc:
  disabled const subselect item evaluation in
  view prepare mode.
sql/item_subselect.cc:
  added Item_subselect::safe_charset_converter which
  prevents const item evaluation in view prepare mode.
sql/item_subselect.h:
  added Item_subselect::safe_charset_converter which
  prevents const item evaluation in view prepare mode.

The problem is that we can not use make_cond_for_table().
This function relies on used_tables() condition
which is not set properly for subqueries.
As result subquery is not filtered out.
The fix is to use remove_eq_conds() function instead
of make_cond_for_table() func. 'remove_eq_conds()'
algorithm relies on const_item() value and it allows
to handle subqueries in right way.


mysql-test/r/having.result:
  test case
mysql-test/t/having.test:
  test case
sql/sql_select.cc:
  The fix is to use remove_eq_conds() function instead
  of make_cond_for_table() function.

            Procedure, while DECIMAL works

Selecting of the CONCAT(...<SP variable>...) result into
a user variable may return wrong data.


Item_func_concat::val_str contains a number of memory
allocation-saving tricks. One of them concatenates
strings inplace inserting the value of one string
at the beginning of the other string. However,
this trick didn't care about strings those points
to the same data buffer: this is possible when
a CONCAT() parameter is a stored procedure variable -
Item_sp_variable::val_str() uses the intermediate
Item_sp_variable::str_value field, where it may
store a reference to an external buffer.


The Item_func_concat::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return
a pointer to an internal Item member variable
that may reference to a buffer provided.


mysql-test/r/func_concat.result:
  Test case for the bug #40625.
mysql-test/t/func_concat.test:
  Test case for the bug #40625.
sql/item_strfunc.cc:
  Bug #40625: Concat fails on DOUBLE values in a Stored
              Procedure, while DECIMAL works
  
  The Item_func_concat::val_str function has been
  modified to take into account val_str functions
  (such as Item_sp_variable::val_str) that return
  a pointer to an internal Item member variable
  that may reference to a buffer provided.

       on index

'my_decimal' class has two members which can be used to access the 
value. The member variable buf (inherited from parent class decimal_t) 
is set to member variable buffer so that both are pointing to same value.

Item_copy_decimal::copy() uses memcpy to clone 'my_decimal'. The member
buffer is declared as an array and memcpy results in copying the values
of the array, but the inherited member buf, which should be pointing at
the begining of the array 'buffer' starts pointing to the begining of 
buffer in original object (which is being cloned). Further updates on 
'my_decimal' updates only the inherited member 'buf' but leaves 
buffer unchanged.

Later when the new object (which now holds a inconsistent value) is cloned
again using proper cloning function 'my_decimal2decimal' the buf pointer
is fixed resulting in loss of the current value.

Using my_decimal2decimal instead of memcpy in Item_copy_decimal::copy()
fixed this problem.


mysql-test/r/subselect.result:
  Updated result file after addding test case for bug#47904.
mysql-test/t/subselect.test:
  Added test case for bug#47904.
sql/item.cc:
  Memcopy shouldn't be used to clone my_decimal. Use my_decimal2decimal
  instead.

            data and index files

It was possible if DATA/INDEX DIRECTORY is pointing to
symlinked MySQL data home directory.

Do not allow to drop data/index files implicitly symlinked
to data home directory. For such tables remove symlink only.

mysql-test/r/symlink.result:
  A test case for BUG#40980.
mysql-test/t/symlink.test:
  A test case for BUG#40980.
storage/myisam/mi_delete_table.c:
  Do not allow to drop data/index files implicitly symlinked
  to data home directory. For such tables remove symlink only.

Detailed revision comments:

r6900 | mmakela | 2010-03-29 13:54:57 +0300 (Mon, 29 Mar 2010) | 5 lines
branches/zip: Merge c6899 from branches/innodb+:

Add debug assertions to track down Bug #52360.
hash_table_t::magic_n: Add HASH_TABLE_MAGIC_N checks, which were fully absent.
ut_hash_ulint(): Assert table_size > 0 before division.