Commit graph

19931 commits

Author SHA1 Message Date
Gleb Shchepa
71082fd17d manual merge 5.1-bugteam --> 5.5-bugteam (bug 52160) 2010-11-01 02:23:37 +03:00
Gleb Shchepa
20d704978d Bug : crash and inconsistent results when grouping
by a function and column

The bugreport reveals two different bugs about grouping
on a function:

1) grouping by the TIME_TO_SEC function result caused
   a server crash or wrong results and
2) grouping by the function returning a blob caused
   an unexpected "Duplicate entry" error and wrong
   result.

Details for the 1st bug:

TIME_TO_SEC() returns NULL if its argument is invalid (empty
string for example). Thus its nullability depends not only
on the nullability of its arguments but also on their values.
Fixed by (overoptimistically) setting TIME_TO_SEC() to be
nullable despite the nullability of its arguments.

Details for the 2nd bug:

The server is unable to create indices on blobs without
explicit blob key part length. However, this fact was
ignored for blob function result fields of GROUP BY
intermediate tables.
Fixed by disabling GROUP BY index creation for blob
function result fields like regular blob fields.


mysql-test/r/func_time.result:
  Test case for bug .
mysql-test/r/type_blob.result:
  Test case for bug .
mysql-test/t/func_time.test:
  Test case for bug .
mysql-test/t/type_blob.test:
  Test case for bug .
sql/item_timefunc.h:
  Bug : crash and inconsistent results when grouping
              by a function and column
  
  TIME_TO_SEC() returns NULL if its argument is invalid (empty
  string for example). Thus its nullability depends not only
  Fixed by (overoptimistically) setting TIME_TO_SEC() to be
  nullable despite the nullability of its arguments.
sql/sql_select.cc:
  Bug : crash and inconsistent results when grouping
              by a function and column
  
  The server is unable to create indices on blobs without
  explicit blob key part length. However, this fact was
  ignored for blob function result fields of GROUP BY
  intermediate tables.
  Fixed by disabling GROUP BY index creation for blob
  function result fields like regular blob fields.
2010-10-31 19:04:38 +03:00
Sven Sandberg
c4a4119829 wL#5625: Deprecate mysqlbinlog options --base64-output=always and --base64-output
Adds deprecation warning for the mysqlbinlog options
--base64-output=always and --base64-output.
A warning is printed when the flags are used,
and also when running mysqlbinlog --help.


client/mysqlbinlog.cc:
  Give a warning for --base64-output=always and --base64-output,
  and print warning in mysqlbinlog --help.
mysql-test/r/mysqlbinlog.result:
  updated result file
mysql-test/t/mysqlbinlog.test:
  Test that mysqlbinlog --base64-output=always gives a warning.
2010-10-29 16:56:58 +02:00
Georgi Kodinov
50d18aa2d5 merge 2010-10-27 09:32:26 +02:00
Alexander Nozdrin
e86b6c0db4 Patch for Bug#55850 (Trigger warnings not cleared).
The problem was that the warnings risen by a trigger were not cleared upon
successful completion. The warnings should be cleared if the trigger completes
successfully.

The fix is to skip merging warnings into caller's Warning Info for triggers.
2010-10-26 15:48:08 +04:00
Horst.Hunger
06a263e2b3 Due to failing on Freebsd. 2010-10-25 12:24:26 +02:00
Jon Olav Hauglid
1ecc17737f Merge from mysql-5.5-runtime to mysql-5.5-bugteam
No conflicts
2010-10-22 14:13:03 +02:00
Horst.Hunger
d63cbdde8e Due to issues with merge. 2010-10-22 10:20:17 +02:00
Jon Olav Hauglid
a776e5f3d2 Merge from mysql-5.5-bugteam to mysql-5.5-runtime
No conflicts
2010-10-21 16:28:29 +02:00
Horst.Hunger
d6af9bef7a due to merge 2010-10-20 16:56:09 +02:00
Konstantin Osipov
08c5798839 Merge 5.5-bugteam -> 5.5-runtime. 2010-10-19 19:20:25 +04:00
Magne Mahre
95d91c0f57 Bug crash with lower_case_table_names=2 and foreign key
data dictionary confusion

On file systems with case insensitive file names, and
lower_case_table_names set to '2', the server could crash
due to a table definition cache inconsistency.  This is 
the default setting on MacOSX, but may also be set and
used on MS Windows.

The bug is caused by using two different strategies for
creating the hash key for the table definition cache, resulting
in failure to look up an entry which is present in the cache,
or failure to delete an existing entry.  One strategy was to
use the real table name (with case preserved), and the other
to use a normalized table name (i.e a lower case version).

This is manifested in two cases.  One is  during 'DROP DATABASE', 
where all known files are removed.  The removal from
the table definition cache is done via a generated list of
TABLE_LIST with keys (wrongly) created using the case preserved 
name.  The other is during CREATE TABLE, where the cache lookup
is also (wrongly) based on the case preserved name.
   
The fix was to use only the normalized table name when
creating hash keys.


sql/sql_db.cc:
  Normalize table name (i.e lower case it)
sql/sql_table.cc:
  table_name contains the normalized name
  alias contains the real table name
2010-10-19 12:27:09 +02:00
Jon Olav Hauglid
8f73bddc9a Merge from mysql-5.5-bugteam to mysql-5.5-runtime
No conflicts
2010-10-19 11:26:45 +02:00
Tor Didriksen
a6df37dbbf Bug Assertion `field_length <= 255' failed.
After the fix for
Bug  Assertion failed: width > 0 && to != ((void *)0), file .\dtoa.c
we no longer try to allocate a string of length 'field_length'
so the asserts are relevant only for ZEROFILL columns.



mysql-test/r/select.result:
  Add test case for Bug#57203
mysql-test/t/select.test:
  Add test case for Bug#57203
sql/field.cc:
  Rewrite the DBUG_ASSERTS on field_length.
2010-10-19 08:45:18 +02:00
Magne Mahre
b61b785285 Merge from mysql-5.1-bugteam to mysql-5.5-bugteam
Only test case is merged, as the fix was already
present in 5.5 code
2010-10-19 12:29:21 +02:00
Dmitry Shulga
4053a5a448 Follow-up for bug#36742: changed results for test ipv4_as_ipv6 because hostname is case-insensitive. 2010-10-18 23:20:26 +07:00
Dmitry Shulga
1e2f4f68bd Auto-merge from mysql-5.1-bugteam for bug#36742. 2010-10-18 22:38:12 +07:00
Dmitry Shulga
cdddc7bfd5 Follow up for bug#36742. Changed test case for bug#19828
because currently hostname stored in db in lowercase.
2010-10-18 21:03:53 +07:00
Konstantin Osipov
248625d910 A fix and a test case for Bug#56540 "Exception (crash) in
sql_show.cc during rqg_info_schema test on Windows".

Ensure we do not access freed memory when filling
information_schema.views when one of the views
could not be properly opened.



mysql-test/r/information_schema.result:
  Update results - a fix for Bug#56540.
mysql-test/t/information_schema.test:
  Add a test case for Bug#56540
sql/sql_base.cc:
  Push an error into the Diagnostics area
  when we return an error.
  This directs get_all_tables() to the execution
  branch which doesn't involve 'process_table()'
  when no table/view was opened.
sql/sql_show.cc:
  Do not try to access underlying table fields
  when opening of a view failed. The underlying
  table is closed in that case, and accessing
  its fields may lead to dereferencing a damaged 
  pointer.
2010-10-14 20:56:56 +04:00
Jon Olav Hauglid
b5be2fbc8d Bug Assertion `thd->transaction.stmt.is_empty() ||
thd->in_sub_stmt || (thd->state..

OPTIMIZE TABLE is not directly supported by InnoDB. Instead,
recreate and analyze of the table is done. After recreate,
the table is closed and locks are released before the table
is reopened and locks re-acquired for the analyze phase.

This assertion was triggered if OPTIMIZE TABLE failed to
acquire thr_lock locks before starting the analyze phase.
The assertion tests (among other things) that there no
active statement transaction. However, as part of acquiring
the thr_lock lock, external_lock() is called for InnoDB
tables and this causes a statement transaction to be started.
If thr_multi_lock() later fails (e.g. due to timeout),
the failure handling code causes this assert to be triggered.

This patch fixes the problem by doing rollback of the
current statement transaction in case open_ltable (used by
OPTIMIZE TABLE) fails to acquire thr_lock locks.

Test case added to lock_sync.test.
2010-10-13 16:15:28 +02:00
Dmitry Shulga
333434d23b Auto-merge from mysql-5.1-bugteam for bug#36742. 2010-10-13 13:27:03 +07:00
Dmitry Shulga
8169faec27 Fixed bug#36742 - GRANT hostname case handling inconsistent.
mysql-test/r/grant.result:
  It was added result for test case for bug#36742.
mysql-test/t/grant.test:
  It was added test case for bug#36742.
sql/sql_yacc.yy:
  It was added convertation of host name part of user name to lowercase.
2010-10-13 12:28:58 +07:00
Alexander Nozdrin
ba084605e8 Auto-merge from mysql-5.5-bugteam. 2010-10-13 01:17:22 +04:00
Dmitry Lenev
1af8cfa094 Merged recent changes from mysql-5.5-bugteam into
mysql-5.5-runtime tree.
2010-10-08 20:33:46 +04:00
Davi Arnaut
15ccca1d55 Bug#56822: Add a thread state for sessions waiting on the query cache lock
Only wait for a single debug signal at a time as the signal state
is global. Also, do not activate the query cache debug sync points
if the thread has no associated THD session.

mysql-test/t/query_cache_debug.test:
  Only wait for a single debug signal at a time as the signal state
  is global.
sql/sql_cache.cc:
  Do not execute the debug sync point if the thread has no associated
  THD session. This scenario happens for federated threads.
2010-10-08 09:16:20 -03:00
Tor Didriksen
c8d7a31f35 Bug#57209 valgrind + Assertion failed: dst > buf
Buffer overrun when trying to format DBL_MAX


mysql-test/r/func_math.result:
  Add test case for Bug#57209
mysql-test/t/func_math.test:
  Add test case for Bug#57209
sql/item_strfunc.cc:
  Allocate a larger buffer for the result.
2010-10-08 11:52:09 +02:00
Alexey Botchkov
42dc7264c0 Bug#35269 mysqlcheck behaves different depending on order of parameters
Issue an error if user specifies multiple commands to run.
        Also there was an unnoticed bug that DO_CHECK was actually 0 which lead
        to wrong actions in some cases.
        The mysqlcheck.test contained commands with the suspicious meaning
        for the above reason. Extra commands removed from there.

per-file commands:
  client/mysqlcheck.c
Bug#35269      mysqlcheck behaves different depending on order of parameters
        Drop with an error if multiple commands.
  mysql-test/r/mysqlcheck.result
Bug#35269      mysqlcheck behaves different depending on order of parameters
        result completed.
  mysql-test/t/mysqlcheck.test
Bug#35269      mysqlcheck behaves different depending on order of parameters
        testcase added.
        not-working commands removed from some mysqlcheck calls.
2010-10-08 12:09:47 +05:00
Davi Arnaut
36051b0106 Bug#56822: Add a thread state for sessions waiting on the query cache lock
The problem was that threads waiting on the query cache lock
are not easily seen due to the lack of a state indicating that
the thread is waiting on the said lock. This made it difficult
for users to quickly spot (for example, via SHOW PROCESSLIST)
a query cache contention problem.

The solution is to update the thread state when the query cache
lock needs to be acquired. Whenever the lock is to be acquired,
the thread state is updated to "Waiting for query cache lock"
and is reset once the lock is granted or the wait is interrupted.
The intention is to make query cache related hangs more evident.

To further investigate query cache related locking problems, one
may use PERFORMANCE_SCHEMA to track the overhead associated with
the locking bits and determine which particular lock is being a
contention point.

sql/sql_cache.cc:
  Set and reset the thread state whenever a attempt to lock the
  query cache is made.
  
  Use DEBUG_SYNC instead of the now unnecessary wait_for_kill hack.
2010-10-07 19:51:37 -03:00
Evgeny Potemkin
7365a389a3 Auto-merged. 2010-10-07 20:39:24 +04:00
Evgeny Potemkin
731dcfc7ff Bug#57095: Wrongly chosen expression cache type led to a wrong result.
The coalesce function returned DATETIME type due to a DATETIME argument, but
since it's not a date/time function it can't return correct int value for
it. Nevertheless Item_datetime_cache was chosen to cache coalesce's result
and that led to a wrong result.

Now Item_datetime_cache is used only for those function that could return
correct int representation of DATETIME values.


mysql-test/r/type_datetime.result:
  Added a test case for the bug#57095.
mysql-test/t/type_datetime.test:
  Added a test case for the bug#57095.
sql/item.cc:
  Bug#57095: Wrongly chosen expression cache type led to a wrong result.
  Now Item_datetime_cache is used only for those function that could return
  correct int representation of DATETIME values.
2010-10-07 20:16:30 +04:00
Dmitry Lenev
eaae675279 Fix for bug#57061 "User without privilege on routine can
discover its existence".

The problem was that user without any privileges on 
routine was able to find out whether it existed or not.
DROP FUNCTION and DROP PROCEDURE statements were 
checking if routine being dropped existed and reported 
ER_SP_DOES_NOT_EXIST error/warning before checking 
if user had enough privileges to drop it.

This patch solves this problem by changing code not to 
check if routine exists before checking if user has enough 
privileges to drop it. Moreover we no longer perform this 
check using a separate call instead we rely on 
sp_drop_routine() returning SP_KEY_NOT_FOUND if routine 
doesn't exist.

This change also simplifies one of upcoming patches
refactoring global read lock implementation.

mysql-test/r/grant.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence". Removed
  DROP PROCEDURE/FUNCTION statements which have started to
  fail after this fix (correctly). There is no need in
  dropping routines in freshly created database anyway.
mysql-test/r/sp-security.result:
  Added new test case for bug#57061 "User without privilege
  on routine can discover its existence". Updated existing
  tests according to new behaviour.
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/suite/funcs_1/storedproc/storedproc_06.inc:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence".
  Now we drop routines under user which has enough
  privileges to do so.
mysql-test/t/grant.test:
  Updated test case after fixing bug#57061 "User without
  privilege on routine can discover its existence". Removed
  DROP PROCEDURE/FUNCTION statements which have started to
  fail after this fix (correctly). There is no need in
  dropping routines in freshly created database anyway.
mysql-test/t/sp-security.test:
  Added new test case for bug#57061 "User without privilege
  on routine can discover its existence". Updated existing
  tests according to new behaviour.
sql/sp.cc:
  Removed sp_routine_exists_in_table() which is no longer
  used.
sql/sp.h:
  Removed sp_routine_exists_in_table() which is no longer
  used.
sql/sql_parse.cc:
  When dropping routine we no longer check if routine exists 
  before checking if user has enough privileges to do so. 
  Moreover we no longer perform this check using a separate 
  call instead we rely on sp_drop_routine() returning 
  SP_KEY_NOT_FOUND if routine doesn't exist.
2010-10-07 20:01:17 +04:00
Sergey Vojtovich
85d023eb38 Merge WL#5496 and WL#5341 to 5.5-bugteam. 2010-10-07 19:52:34 +04:00
Jon Olav Hauglid
e486d21dfc Merge from mysql-5.5-runtime to mysql-5.5-bugteam
No conflicts
2010-10-07 14:12:33 +02:00
Martin Hansson
95f8d9a2a4 Bug#56423: Different count with SELECT and CREATE SELECT queries
This is the 5.5 version of the fix. The 5.1 version was too complicated to
merge and was null merged.

This is a regression from the fix for bug no 38999. A storage engine capable
of reading only a subset of a table's columns updates corresponding bits in
the read buffer to signal that it has read NULL values for the corresponding
columns. It cannot, and should not, update any other bits. Bug no 38999
occurred because the implementation of UPDATE statements compare the NULL bits
using memcmp, inadvertently comparing bits that were never requested from the
storage engine. The regression was caused by the storage engine trying to
alleviate the situation by writing to all NULL bits, even those that it had no
knowledge of. This has devastating effects for the index merge algorithm,
which relies on all NULL bits, except those explicitly requested, being left
unchanged.

The fix reverts the fix for bug no 38999 in both InnoDB and InnoDB plugin and
changes the server's method of comparing records. For engines that always read
entire rows, we proceed as usual. For engines capable of reading only select
columns, the record buffers are now compared on a column by column basis. An
assertion was also added so that non comparable buffers are never read. Some
relevant copy-pasted code was also consolidated in a new function.
2010-10-07 12:01:51 +02:00
Evgeny Potemkin
5dc76bfabf Auto-merged. 2010-10-07 12:17:08 +04:00
Martin Hansson
30f57b3323 Bug#56423: Different count with SELECT and CREATE SELECT queries
This is a regression from the fix for bug no 38999. A storage engine capable
of reading only a subset of a table's columns updates corresponding bits in
the read buffer to signal that it has read NULL values for the corresponding
columns. It cannot, and should not, update any other bits. Bug no 38999
occurred because the implementation of UPDATE statements compare the NULL bits
using memcmp, inadvertently comparing bits that were never requested from the
storage engine. The regression was caused by the storage engine trying to
alleviate the situation by writing to all NULL bits, even those that it had no
knowledge of. This has devastating effects for the index merge algorithm,
which relies on all NULL bits, except those explicitly requested, being left
unchanged.

The fix reverts the fix for bug no 38999 in both InnoDB and InnoDB plugin and
changes the server's method of comparing records. For engines that always read
entire rows, we proceed as usual. For engines capable of reading only select
columns, the record buffers are now compared on a column by column basis. An
assertion was also added so that non comparable buffers are never read. Some
relevant copy-pasted code was also consolidated in a new function.
2010-10-07 10:13:11 +02:00
Evgeny Potemkin
3c9c7efb3b Bug#57039: constant subtime expression returns incorrect result.
The subtime function wasn't able to produce correct int representation of
its result. For constant expressions the Item_datetime_cache is used to
speedup evaluation and Item_datetime_cache expects underlying item to return
correct int representation of DATETIME value. These two factors combined led
to a wrong query result.

Now the Item_func_add_time has function val_datetime which performs the
calculation and saves result into given MYSQL_TIME struct, it also sets
null_value to appropriate value. val_int and val_str member functions
convert the result obtained from val_datetime to int or string respectively
and returns it.

mysql-test/r/func_time.result:
  Added a test case for the bug#57039.
mysql-test/t/func_time.test:
  Added a test case for the bug#57039.
sql/item_timefunc.cc:
  Bug#57039: constant subtime expression returns incorrect result.
  Now the Item_func_add_time has function val_datetime which performs the
  calculation and saves result into given MYSQL_TIME struct, it also sets
  null_value to appropriate value. val_int and val_str member functions
  convert the result obtained from val_datetime to int or string respectively
  and returns it.
sql/item_timefunc.h:
  Bug#57039: constant subtime expression returns incorrect result.
2010-10-07 11:07:56 +04:00
Davi Arnaut
a5efb91dea Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c
Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock

- Incompatible change: truncate no longer resorts to a row by
row delete if the storage engine does not support the truncate
method. Consequently, the count of affected rows does not, in
any case, reflect the actual number of rows.

- Incompatible change: it is no longer possible to truncate a
table that participates as a parent in a foreign key constraint,
unless it is a self-referencing constraint (both parent and child
are in the same table). To work around this incompatible change
and still be able to truncate such tables, disable foreign checks
with SET foreign_key_checks=0 before truncate. Alternatively, if
foreign key checks are necessary, please use a DELETE statement
without a WHERE condition.

Problem description:

The problem was that for storage engines that do not support
truncate table via a external drop and recreate, such as InnoDB
which implements truncate via a internal drop and recreate, the
delete_all_rows method could be invoked with a shared metadata
lock, causing problems if the engine needed exclusive access
to some internal metadata. This problem originated with the
fact that there is no truncate specific handler method, which
ended up leading to a abuse of the delete_all_rows method that
is primarily used for delete operations without a condition.

Solution:

The solution is to introduce a truncate handler method that is
invoked when the engine does not support truncation via a table
drop and recreate. This method is invoked under a exclusive
metadata lock, so that there is only a single instance of the
table when the method is invoked.

Also, the method is not invoked and a error is thrown if
the table is a parent in a non-self-referencing foreign key
relationship. This was necessary to avoid inconsistency as
some integrity checks are bypassed. This is inline with the
fact that truncate is primarily a DDL operation that was
designed to quickly remove all data from a table.

mysql-test/suite/innodb/t/innodb-truncate.test:
  Add test cases for truncate and foreign key checks.
  Also test that InnoDB resets auto-increment on truncate.
mysql-test/suite/innodb/t/innodb.test:
  FK is not necessary, test is related to auto-increment.
  
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
mysql-test/suite/innodb/t/innodb_mysql.test:
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
  
  Use delete instead of truncate, test is used to check
  the interaction of FKs, triggers and delete.
mysql-test/suite/parts/inc/partition_check.inc:
  Fix typo.
mysql-test/suite/sys_vars/t/foreign_key_checks_func.test:
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
mysql-test/t/mdl_sync.test:
  Modify test case to reflect and ensure that truncate takes
  a exclusive metadata lock.
mysql-test/t/trigger-trans.test:
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
sql/ha_partition.cc:
  Reorganize the various truncate methods. delete_all_rows is now
  passed directly to the underlying engines, so as truncate. The
  code responsible for truncating individual partitions is moved
  to ha_partition::truncate_partition, which is invoked when a
  ALTER TABLE t1 TRUNCATE PARTITION p statement is executed.
  
  Since the partition truncate no longer can be invoked via
  delete, the bitmap operations are not necessary anymore. The
  explicit reset of the auto-increment value is also removed
  as the underlying engines are now responsible for reseting
  the value.
sql/handler.cc:
  Wire up the handler truncate method.
sql/handler.h:
  Introduce and document the truncate handler method. It assumes
  certain use cases of delete_all_rows.
  
  Add method to retrieve the list of foreign keys referencing a
  table. Method is used to avoid truncating tables that are
  parent in a foreign key relationship.
sql/share/errmsg-utf8.txt:
  Add error message for truncate and FK.
sql/sql_lex.h:
  Introduce a flag so that the partition engine can detect when
  a partition is being truncated. Used to give a special error.
sql/sql_parse.cc:
  Function mysql_truncate_table no longer exists.
sql/sql_partition_admin.cc:
  Implement the TRUNCATE PARTITION statement.
sql/sql_truncate.cc:
  Change the truncate table implementation to use the new truncate
  handler method and to not rely on row-by-row delete anymore.
  
  The truncate handler method is always invoked with a exclusive
  metadata lock. Also, it is no longer possible to truncate a
  table that is parent in some non-self-referencing foreign key.
storage/archive/ha_archive.cc:
  Rename method as the description indicates that in the future
  this could be a truncate operation.
storage/blackhole/ha_blackhole.cc:
  Implement truncate as no operation for the blackhole engine in
  order to remain compatible with older releases.
storage/federated/ha_federated.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required to support partition truncate as this
  form of truncate does not implement the drop and recreate
  protocol.
storage/heap/ha_heap.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required to support partition truncate as this
  form of truncate does not implement the drop and recreate
  protocol.
storage/ibmdb2i/ha_ibmdb2i.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required to support partition truncate as this
  form of truncate does not implement the drop and recreate
  protocol.
storage/innobase/handler/ha_innodb.cc:
  Rename delete_all_rows to truncate. InnoDB now does truncate
  under a exclusive metadata lock.
  
  Introduce and reorganize methods used to retrieve the list
  of foreign keys referenced by a or referencing a table.
storage/myisammrg/ha_myisammrg.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required in order to remain compatible with earlier
  releases where truncate would resort to a row-by-row delete.
2010-10-06 11:34:28 -03:00
Alexander Barkov
401e6c909c Bug#55744 GROUP_CONCAT + CASE + ucs return garbage
Problem: CASE didn't work with a mixture of different character
sets in THEN/ELSE in some cases.
This happened because after character set aggregation
newly created Item_func_conv_charset items corresponding
to THEN/ELSE arguments were not put back to args[] array.

Fix:
put all Item_func_conv_charset back to args[].


  @ mysql-test/include/ctype_numconv.inc
  @ mysql-test/r/ctype_ucs.result
  Adding tests

  @ sql/item_cmpfunc.cc
  Put "agg" back to args[] after character set aggregation.
2010-10-06 16:15:59 +04:00
Georgi Kodinov
93b7578d21 merge 2010-10-06 13:02:11 +03:00
Jon Olav Hauglid
4386615050 Merge from mysql-5.5-bugteam to mysql-5.5-runtime. 2010-10-06 11:29:44 +02:00
Georgi Kodinov
591a69143c merge 5.5-bugteam -> 5.5-security 2010-10-06 12:17:22 +03:00
Magne Mahre
653f14c265 Bug#56452 Assertion failed: thd->transaction.stmt.is_empty() ||
thd->in_sub_stmt
      
In a precursor patch for Bug#52044 
(revid:bzr/kostja@stripped), a
number of reorganizations of code was made. In addition some
assertions were added to ensure the correct transactional state.
      
The reorganization had a small glitch so statements that was
active in the query cache was not followed by a
statement commit/rollback (this code was removed). A section
in the trans_commit_stmt/trans_rollback_stmt code is to
clear the thd->transaction.stmt list of affected storage
engines.  When a new statement is initiated, an assert
introduced by the 523044 patch checks if this list is cleared.
When the query cache is accessed, this list may be populated,
and since it's not committed it will not be cleared.
      
This fix adds explicit statement commit or rollback for
statements that is contained in the query cache.
2010-10-06 11:01:24 +02:00
Georgi Kodinov
6f9839d965 merge of 5.1-bugteam into 5.1-security 2010-10-06 11:58:31 +03:00
Jon Olav Hauglid
e53e16a885 Bug Assert in upgrade_shared_lock_to_exclusive()
for ALTER TABLE + MERGE tables

The patch for Bug#56292 changed how metadata locks are taken for MERGE
tables. After the patch, locking the MERGE table will also lock the
children tables with the same metadata lock type. This means that 
LOCK TABLES on a MERGE table also will implicitly do LOCK TABLES on
the children tables.

A consequence of this change, is that it is possible to do LOCK TABLES
on a child table both explicitly and implicitly with the same statement
and that these two locks can be of different strength. For example,
LOCK TABLES child READ, merge WRITE.

In LOCK TABLES mode, we are not allowed to take new locks and each
statement must therefore try to find an existing TABLE instance with
a suitable lock. The code that searched for a suitable TABLE instance,
only considered table level locks. If a child table was locked twice,
it was therefore possible for this code to find a TABLE instance with
suitable table level locks but without suitable metadata lock.

This problem caused the assert in upgrade_shared_lock_to_exclusive()
to be triggered as it tried to upgrade a MDL_SHARED lock to
EXCLUSIVE. The problem was a regression caused by the patch for
Bug#56292.

This patch fixes the problem by partially reverting the changes
done by Bug#56292. Now, the children tables will only use the
same metadata lock as the MERGE table for MDL_SHARED_NO_WRITE
when not in locked tables mode. This means that LOCK TABLE
on a MERGE table will not implicitly lock the children tables.
This still fixes the original problem in Bug#56292 without
causing a regression.

Test case added to merge.test.
2010-10-06 09:56:29 +02:00
Georgi Kodinov
1744b54082 fixed failing test cases 2010-10-05 15:26:49 +03:00
Georgi Kodinov
292a72a043 merged mysql-5.1 into mysql-5.1-bugteam 2010-10-05 11:11:56 +03:00
Jon Olav Hauglid
998eeea6f2 Merge from mysql-5.5-bugteam to mysql-5.5-runtime. 2010-10-04 16:19:11 +02:00
Georgi Kodinov
f206172ba9 worklog 1054: Fixed test suite typos 2010-10-04 16:09:37 +03:00
Georgi Kodinov
8789c79723 merge 2010-10-04 15:42:16 +03:00