1
0
mirror of https://github.com/MariaDB/server.git synced 2025-11-02 02:53:04 +03:00
Commit Graph

27648 Commits

Author SHA1 Message Date
Mattias Jonsson
4770f8d415 merge 2010-09-10 11:50:38 +02:00
Bjorn Munch
d898106014 merge 55178,55413,56383 2010-09-10 09:59:40 +02:00
Bjorn Munch
4b1d6118e8 merge 55178,55413,56383 2010-09-10 09:58:26 +02:00
Jon Olav Hauglid
e01a1bfdb8 Merge from mysql-5.5-bugfixing to mysql-5.5-runtime. 2010-09-10 09:26:00 +02:00
Marc Alff
2779f0aad1 Bug#56324 Race Condition while shutting down MySQL: "PSI_server"
Before this fix, the server could crash during shutdown,
due to race conditions, that occured when killing the server.

In particular, the performance schema instrumentation handle,
PSI_server, and the performance schema itself would be cleaned up
too soon, causing race conditions with a running kill server thread.

The specifics of the race condition found are that:
the main thread executing "PSI_server= NULL" can cause crashes in
other threads still running, which are executing
"if (PSI_server != NULL) PSI_server->xxx()"
as part of the performance schema instrumentation.

While the bug was reported for the kill server thread,
in theory the same crash could happen with the signal thread,
as found by code analysis.

The correct fix would be to only shutdown the performance schema
and set PSI_server to NULL after every other thread is guaranteed
to be completed, including the kill_server_thread.

However, due to the existing mysqld server design, this is not the case.
See in particular bug number 56666.

The work around used to fix this race condition is to simply not
perform the call to shutdown_performance_schema() when the server exits,
and to keep the PSI_server pointer unchanged.

This will cause memory leaks to be reported by tools like valgrind,
but no memory leak actually happen because the process is about to exit().

As a result, the file mysql-test/valgrind.supp has been updated
to filter out these false positive messages.

This code has been tested with running in a loop the following
tests in parallel, which have been known to fail with race conditions
in the past:
- rpl_change_master
- binlog_max_extension
- events_restart
- rpl_heartbeat_basic
and no crash of test failure has been seen with the changed code.
2010-09-09 15:33:35 -06:00
Marc Alff
712a8a2eb9 local merge 2010-09-09 09:26:55 -06:00
Alexey Kopytov
637c7529de Manual merge of the fix for bug #54190 and the addendum patch
to 5.5 (removed one test case as it is no longer valid).
2010-09-09 19:00:33 +04:00
Dmitry Lenev
3326614df1 Fix for bug #55273 "FLUSH TABLE tm WITH READ LOCK for Merge
table causes assert failure".

Attempting to use FLUSH TABLE table_list WITH READ LOCK
statement for a MERGE table led to an assertion failure if
one of its children was not present in the list of tables
to be flushed. The problem was not visible in non-debug builds.

The assertion failure was caused by the fact that in such
situations FLUSH TABLES table_list WITH READ LOCK implementation
tried to use (e.g. lock) such child tables without acquiring
metadata lock on them. This happened because when opening tables
we assumed metadata locks on all tables were already acquired
earlier during statement execution and a such assumption was
false for MERGE children.

This patch fixes the problem by ensuring at open_tables() time
that we try to acquire metadata locks on all tables to be opened. 
For normal tables such requests are satisfied instantly since
locks are already acquired for them. For MERGE children metadata
locks are acquired in normal fashion.

Note that FLUSH TABLES merge_table WITH READ LOCK will lock for
read both the MERGE table and its children but will flush only 
the MERGE table. To flush children one has to mention them in table
list explicitly. This is expected behavior and it is consistent with
usage patterns for this statement (e.g. in mysqlhotcopy script).
2010-09-09 18:29:14 +04:00
Alexey Kopytov
df198b5f6a Automerge. 2010-09-09 16:48:06 +04:00
Alexey Kopytov
9066714c81 Bug #54190: Comparison to row subquery produces incorrect
result

Row subqueries producing no rows were not handled as UNKNOWN
values in row comparison expressions.

That was a result of the following two problems:

1. Item_singlerow_subselect did not mark the resulting row
value as NULL/UNKNOWN when no rows were produced.

2. Arg_comparator::compare_row() did not take into account that
a whole argument may be NULL rather than just individual scalar
values.

Before bug#34384 was fixed, the above problems were hidden
because an uninitialized (i.e. without any stored value) cached
object would appear as NULL for scalar values in a row subquery
returning an empty result. After the fix
Arg_comparator::compare_row() would try to evaluate
uninitialized cached objects.

Fixed by removing the aforementioned problems.
2010-09-09 16:46:13 +04:00
Ramil Kalimullin
5eb7154faa Automerge. 2010-09-09 16:43:45 +04:00
Evgeny Potemkin
89b53f9908 Auto-merged. 2010-09-09 16:02:02 +04:00
Ramil Kalimullin
9080f681b4 Fix for bug#56679: gis.test: valgrind error
Item_func_spatial_collection::fix_length_and_dec()
changed to use argument's print() method to print
the ER_ILLEGAL_VALUE_FOR_TYPE error.
2010-09-09 13:40:17 +04:00
Marc Alff
92c6d9fc75 Bug#56528 Increased server footprint with MTR
With recent changes in the performance schema default sizing parameters,
the memory used by a mysqld binary increased accordingly.

This negatively affects the MTR test suite,
because running several tests in parallel now consumes more ressources.

The fix is to leave the default production values unchanged,
and to configure the MTR environment to limit memory
used when running tests in the test suite, which is ok
because only a few objects are typically used within a test script.

This fix:
- changed the default configuration in MTR to use less memory
- adjusted the performance schema tests accordingly

Note that 1,000 mutex instances was too short and caused test failures
in the past in team trees, so the default used is now 10,000 in MTR.

The amount of memory used by the performance schema itself
can be observed with the statement SHOW ENGINE PERFORMANCE_SCHEMA STATUS
2010-09-08 12:01:12 -06:00
Jon Olav Hauglid
51a3375c98 Bug #56292 Deadlock with ALTER TABLE and MERGE tables
ALTER TABLE on a MERGE table could cause a deadlock with two
other connections if we reached a situation where:

1) A connection doing ALTER TABLE can't upgrade to MDL_EXCLUSIVE on the
parent table, but holds TL_READ_NO_INSERT on the child tables.
2) A connection doing DELETE on a child table can't get TL_WRITE on it
since ALTER TABLE holds TL_READ_NO_INSERT.
3) A connection doing SELECT on the parent table can't get TL_READ on 
the child tables since TL_WRITE is ahead in the lock queue, but holds
MDL_SHARED_READ on the parent table preventing ALTER TABLE from upgrading.

For regular tables, this deadlock is avoided by having ALTER TABLE
take a MDL_SHARED_NO_WRITE metadata lock on the table. This prevents
DELETE from acquiring MDL_SHARED_WRITE on the table before ALTER TABLE
tries to upgrade to MDL_EXCLUSIVE. In the example above, SELECT would
therefore not be blocked by the pending DELETE as DELETE would not be
able to enter TL_WRITE in the table lock queue.

This patch fixes the problem for merge tables by using the same metadata
lock type for child tables as for the parent table. The child tables will
in this case therefore be locked with MDL_SHARED_NO_WRITE, preventing
DELETE from acquiring a metadata lock and enter into the table lock queue.

Change in behavior: By taking the same metadata lock for child tables
as for the parent table, LOCK TABLE on the parent table will now also
implicitly lock the child tables. Since LOCK TABLE on the parent table
now takes more than one metadata lock, it is possible for LOCK TABLE
... WRITE on the parent table or child tables to give ER_LOCK_DEADLOCK
error.

Test case added to mdl_sync.test.
Merge.test/.result has been updated to reflect the change to LOCK TABLE.
2010-09-08 10:25:37 +02:00
Kristofer Pettersson
ccc7ae0e17 merge 5.1-security => 5.5-security 2010-09-08 09:36:39 +02:00
Sergey Vojtovich
f7da62d2ad main.gis-rtree, main.type_float and main.type_newdecimal
were marked as experimental due to BUG38965.
2010-09-08 00:16:10 +04:00
Kristofer Pettersson
dc285eb7cd Post fix following fix for bug55531: Disabling testcase for
bug 55568 because {1} isn't a valid geometry for a geometry
collection.
2010-09-07 15:43:00 +02:00
Kristofer Pettersson
3a643b0a34 Manual resolve of mysql-test/r/gis.result 2010-09-07 13:34:18 +02:00
Martin Hansson
06b70326ce Merge of fix for Bug#51070. 2010-09-07 12:17:12 +02:00
Kristofer Pettersson
5caea4a995 Bug#55531 crash with conversions of geometry types / strings
Convertion from a floating point number to a string caused a
crash.

During rare circumstances a String object could crash when
it was requested to allocate new memory.
A crash could occcur in Field_double::val_str() because of
a pointer referencing memory inside a String object which was
of unknown size.
And finally, the geometric collection should not accept
arguments which are non geometric.
2010-09-07 11:37:46 +02:00
Martin Hansson
babebf9ceb Bug#51070: Query with a NOT IN subquery predicate returns a wrong result set
The EXISTS transformation has additional switches to catch the known corner
cases that appear when transforming an IN predicate into EXISTS. Guarded
conditions are used which are deactivated when a NULL value is seen in the
outer expression's row. When the inner query block supplies NULL values,
however, they are filtered out because no distinction is made between the
guarded conditions; guarded NOT x IS NULL conditions in the HAVING clause that
filter out NULL values cannot be de-activated in isolation from those that
match values or from the outer expression or NULL's.

The above problem is handled by making the guarded conditions remember whether
they have rejected a NULL value or not, and index access methods are taking
this into account as well. 

The bug consisted of 

1) Not resetting the property for every nested loop iteration on the inner
   query's result.

2) Not propagating the NULL result properly from inner query to IN optimizer.

3) A hack that may or may not have been needed at some point. According to a
   comment it was aimed to fix #2 by returning NULL when FALSE was actually
   the result. This caused failures when #2 was properly fixed. The hack is
   now removed.

The fix resolves all three points.
2010-09-07 11:21:09 +02:00
Dmitry Shulga
417092560c Auto-merge from mysql-5.1-bugteam. 2010-09-07 16:00:41 +07:00
Dmitry Shulga
70807d1473 Fixed bug #55421 - Protocol::end_statement(): Assertion `0' on
multi-table UPDATE IGNORE.
The problem was that if there was an active SELECT statement
during trigger execution, an error risen during the execution
may cause a crash. The fix is to temporary reset LEX::current_select
before trigger execution and restore it afterwards. This way
errors risen during the trigger execution are processed as
if there was no active SELECT.
2010-09-07 15:53:46 +07:00
Martin Hansson
3825f36429 Merge of fix for Bug#54543. Test case only (bug is not present in this tree). 2010-09-07 10:00:52 +02:00
Martin Hansson
3d5b9792e6 Bug#54543: update ignore with incorrect subquery leads to assertion failure:
inited==INDEX

When an error occurs while sending the data in a temporary table there was no
cleanup performed. This caused a failed assertion in the case when different
access methods were used for populating the table vs. retrieving the data from
the table if IGNORE was specified and sql_safe_updates = 0. In this case
execution continues, but the handler expects to continue with the access
method used for row retrieval.

Fixed by doing the cleanup even if errors occur.
2010-09-07 09:58:05 +02:00
Evgeny Potemkin
e408bf4e14 Bug#56271: Wrong comparison result with STR_TO_DATE function
The Item_func_str_to_date class wasn't providing correct integer DATETIME
representation as expected. This led to wrong comparison result and didn't
allowed the STR_TO_DATE function to be used with indexes.
Also, STR_TO_DATE function was inconsisted on throwing warnings/errors.
Fixed now.

val_int and result_as_longlong methods were added to the Item_func_str_to_date
class.
2010-09-07 10:45:00 +04:00
Jimmy Yang
1566c3657e Port fix for bug #53756 from 5.1 built-in to 5.1 plugin. 2010-09-06 22:41:37 -07:00
Georgi Kodinov
1f84bb0c0f merge 2010-09-06 17:04:32 +02:00
Mats Kindahl
788d3c4518 Bug #55966: "plugin" tests fail in 5.5
On Solaris with version 3.4.6, the ha_example.so shared library is built
with DTrace and the server is built without DTrace support. This occurs
because dtrace.cmake disables DTrace support for 3.4.6, but still set
HAVE_DTRACE, which causes probes_mysql.h to include probes_mysql_dtrace.h
instead of probes_mysql_nodtrace.h.

This patch fixes this by not setting HAVE_DTRACE on Solaris for GCC 3.4.6.
2010-09-06 14:45:12 +02:00
Ramil Kalimullin
df798550cc Automerge. 2010-09-06 13:54:44 +04:00
Jon Olav Hauglid
dd4cd40a87 Merge from mysql-5.5-bugfixing to mysql-5.5-runtime. 2010-09-03 09:42:51 +02:00
Vladislav Vaintroub
08e1a5b770 Small fixes in CMake:
create data dir correctly in initial_database target on Windows
 handle case where INSTALL_MYSQLTESTDIR is empty (e.g someone does not want
 to install tests)
2010-09-03 00:17:08 +02:00
Georgi Kodinov
684c3e9e3d merge from 5.5-merge 2010-09-02 16:57:59 +03:00
Alfranio Correia
1ce9eb084f BUG#55961 Savepoint Identifier should be enclosed with backticks
Added backticks to the savepoint identifier.
2010-09-02 14:05:06 +01:00
Jimmy Yang
edbae904ff Merge from mysql-5.1-bugteam to mysql-5.1-security 2010-09-01 17:43:02 -07:00
Magne Mahre
24fc7ca4c8 Bug#39932 "create table fails if column for FK is in different
case than in corr index".
      
Server was unable to find existing or explicitly created supporting
index for foreign key if corresponding statement clause used field
names in case different than one used in key specification and created
yet another supporting index.
In cases when name of constraint (and thus name of generated index)
was the same as name of existing/explicitly created index this led
to duplicate key name error.
      
The problem was that unlike all other code Key_part_spec::operator==()
compared field names in case sensitive fashion. As result routines
responsible for getting rid of redundant generated supporting indexes
for foreign key were not working properly for versions of field names
using different cases.

(backported from mysql-trunk)
2010-09-01 19:38:34 +02:00
Bjorn Munch
4698ed2be8 upmerge 56383 2010-09-01 15:52:31 +02:00
Bjorn Munch
2154211192 merge from 5.5 2010-09-01 15:49:43 +02:00
Alexander Nozdrin
7405361bc3 Auto-merge from mysql-5.5. 2010-09-01 17:12:42 +04:00
Jon Olav Hauglid
370eaa56aa Merge from mysql-5.5-bugfixing to mysql-5.5-runtime. 2010-09-01 14:45:13 +02:00
Alexander Nozdrin
157f080614 Cherry-picking patch for Bug#55980.
Original changeset:
------------------------------------------------------------
revno: 3197
revision-id: alik@sun.com-20100831135426-h5a4s2w6ih1d8q2x
parent: magnus.blaudd@sun.com-20100830120632-u3xzy002mdwueli8
committer: Alexander Nozdrin <alik@sun.com>
branch nick: mysql-5.5-bugfixing
timestamp: Tue 2010-08-31 17:54:26 +0400
message:
  Bug#55980 Character sets: supplementary character _bin ordering is wrong
  
  Problem:
  - ORDER BY for utf8mb4_bin, utf16_bin and utf32_bin returned
    results in a wrong order, because old functions
    (supporting only BMP range) were used to handle these collations.
  - Additionally, utf16_bin did not sort supplementary characters
    between U+D700 and U+E000, as WL#1213 specification specified.
------------------------------------------------------------
2010-08-31 18:22:03 +04:00
Alexander Nozdrin
b75958e665 Disable mysqlhotcopy* test cases due to Bug 54129. 2010-08-31 18:05:35 +04:00
Alexander Nozdrin
8da22a75f3 Bug#55980 Character sets: supplementary character _bin ordering is wrong
Problem:
- ORDER BY for utf8mb4_bin, utf16_bin and utf32_bin returned
  results in a wrong order, because old functions
  (supporting only BMP range) were used to handle these collations.
- Additionally, utf16_bin did not sort supplementary characters
  between U+D700 and U+E000, as WL#1213 specification specified.
2010-08-31 17:54:26 +04:00
Alexander Nozdrin
55c1da5a7e Cherry-picking patch for Bug#56137 from mysql-5.5-runtime.
------------------------------------------------------------
revno: 3124
revision-id: dlenev@mysql.com-20100831090419-rzr5ktekby2gspm1
parent: alik@sun.com-20100827083901-x4wvtc10u9p7gcs9
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-5.5-rt-56137
timestamp: Tue 2010-08-31 13:04:19 +0400
message:
  Bug #56137 "Assertion `thd->lock == 0' failed on upgrading 
  from 5.1.50 to 5.5.6".
  
  Debug builds of the server aborted due to an assertion
  failure when DROP DATABASE statement was run on an
  installation which had outdated or corrupt mysql.proc table.
  Particularly this affected the mysql_upgrade tool which is
  run as part of 5.1 to 5.5 upgrade.
  
  The problem was that sp_drop_db_routines(), which was invoked
  during dropping of the database, could have returned without
  closing and unlocking mysql.proc table in cases when this
  table was not up-to-date with the current server. As a result
  further attempt to open and lock the mysql.event table, which
  was necessary to complete dropping of the database, ended up
  with an assert.
  
  This patch solves this problem by ensuring that
  sp_drop_db_routines() always closes mysql.proc table and
  releases metadata locks on it. This is achieved by changing
  open_proc_table_for_update() function to close tables and
  release metadata locks acquired by it in case of failure.
  This step also makes behavior of the latter function
  consistent with behavior of open_proc_table_for_read()/
  open_and_lock_tables().
  
  
  Test case for this bug was added to sp-destruct.test.
------------------------------------------------------------
2010-08-31 17:49:41 +04:00
Alexander Nozdrin
00eb62847d Cherry-pick patch for Bug#56120 from mysql-5.5-bugfixing. 2010-08-31 17:47:10 +04:00
Bjorn Munch
e59b1980e6 Bug #56383 provide option to restart mysqld after each mtr test
Added --force-restart
2010-08-31 11:27:57 +02:00
Dmitry Lenev
26bc3b34d5 Bug #56137 "Assertion `thd->lock == 0' failed on upgrading
from 5.1.50 to 5.5.6".

Debug builds of the server aborted due to an assertion
failure when DROP DATABASE statement was run on an
installation which had outdated or corrupt mysql.proc table.
Particularly this affected the mysql_upgrade tool which is
run as part of 5.1 to 5.5 upgrade.

The problem was that sp_drop_db_routines(), which was invoked
during dropping of the database, could have returned without
closing and unlocking mysql.proc table in cases when this
table was not up-to-date with the current server. As a result
further attempt to open and lock the mysql.event table, which
was necessary to complete dropping of the database, ended up
with an assert.

This patch solves this problem by ensuring that
sp_drop_db_routines() always closes mysql.proc table and
releases metadata locks on it. This is achieved by changing
open_proc_table_for_update() function to close tables and
release metadata locks acquired by it in case of failure.
This step also makes behavior of the latter function
consistent with behavior of open_proc_table_for_read()/
open_and_lock_tables().


Test case for this bug was added to sp-destruct.test.
2010-08-31 13:04:19 +04:00
Alexander Nozdrin
e4a7db6c67 Auto-merge from mysql-5.5-merge. 2010-08-31 11:55:41 +04:00
Gleb Shchepa
4c47c78c41 automerge 5.1-bugteam --> 5.5-merge (bug 53034) 2010-08-31 02:22:01 +04:00