------------------------------------------------------------
revno: 2572.23.1
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-03-19 09:03:08 -0300
message:
Bug#17954 Threads_connected > Threads_created
The problem is that insert delayed threads are counted as connected
but not as created, leading to a Threads_connected value greater then
the Threads_created value.
The solution is to enforce the documented behavior that the
Threads_connected value shall be the number of currently
open connections and that Threads_created shall be the
number of threads created to handle connections.
mysql-test/r/status.result:
Add test case result for Bug#17954
mysql-test/t/status.test:
Add test case for Bug#17954
sql/mysqld.cc:
Change Threads_connected to reflect the number of
open connections. SHOW_INT type variables are not
reset.
------------------------------------------------------------
revno: 2476.1116.1
committer: davi@mysql.com/endora.local
timestamp: Fri 2007-12-14 10:10:19 -0200
message:
DROP TABLE under LOCK TABLES simultaneous to a FLUSH TABLES
WITH READ LOCK (global read lock) can lead to a deadlock.
The solution is to not wait for the global read lock if the
thread is holding any locked tables.
Related to bugs 23713 and 32395. This issues is being fixed
only on 6.0 because it depends on the fix for bug 25858 --
which was fixed only on 6.0.
------------------------------------------------------------
revno: 2476.784.3
committer: davi@moksha.local
timestamp: Tue 2007-10-02 21:27:31 -0300
message:
Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
When a client (connection) holds a lock on a table and attempts to
drop (obtain a exclusive lock) on a second table that is already
held by a second client and the second client then attempts to
drop the table that is held by the first client, leads to a
circular wait deadlock. This scenario is very similar to trying to
drop (or rename) a table while holding read locks and are
correctly forbidden.
The solution is to allow a drop table operation to continue only
if the table being dropped is write (exclusively) locked, or if
the table is temporary, or if the client is not holding any
locks. Using this scheme prevents the creation of a circular
chain in which each client is waiting for one table that the
next client in the chain is holding.
This is incompatible change, as can be seen by number of tests
cases that needed to be fixed, but is consistent with respect to
behavior of the different scenarios in which the circular wait
might happen.
mysql-test/r/drop.result:
Test case result for Bug#25858
mysql-test/r/group_by.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/insert_notembedded.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table
mysql-test/r/lock.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/lock_multi.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/myisam.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/r/view.result:
Fix test case result wrt drop table under lock tables -- unlock tables
before dropping table.
mysql-test/t/drop.test:
Add test case for Bug#25858
mysql-test/t/group_by.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/insert_notembedded.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock_multi.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/myisam.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/query_cache_notembedded.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/view.test:
Fix test case: unlock tables in preparation for a drop table. In some
circumstances, dropping tables while holding locks leads to a deadlock.
sql/lock.cc:
When trying to obtain a name lock under lock tables, ensure that the table is properly exclusively locked and fail otherwise.
The mentioned on the bug report set of bugs fixes have not be pushed to the main trees.
Fixed with extracting commits done to 6.0-rpl tree and applying them to the main 5.1.
Notes.
1. part of changes - the mtr's specific - were packported to the main 5.0 tree for mtr v1
as http://lists.mysql.com/commits/46562
However, there is no that fix anymore in the mtr v2. (This fact was mailed to mtr maintaining
people).
2. Bug@36929 crash in kill_zombie_dump_threads-> THD::awake() with replication tests
is not backported because the base code of the patch is libevent and that was removed
from the main trees due to its instability.
client/mysqlbinlog.cc:
fixes for BUG#35546
mysql-test/suite/rpl/r/rpl_bug41902.result:
the new tests result file is added.
mysql-test/suite/rpl/t/rpl_bug41902-slave.opt:
conf file for bug41902 testing is added.
mysql-test/suite/rpl/t/rpl_bug41902.test:
regression tests for Bug #41902 is added.
sql/log.cc:
collection of changes due to Bug #48463.
sql/log.h:
collection of changes due to Bug #48463.
sql/rpl_rli.h:
collection of changes due to Bug #48463.
sql/slave.cc:
collection of changes due to Bug #48463.
sql/sql_repl.cc:
collection of changes due to Bug #48463.
Post-push fix: Removed MTRv1 arguments according to the
original patch. Although there is a version check, the patch
was pushed to a 5.1 GA staging tree, while the version check
considers version 5.2. This makes the deprecated parameters
to be used, despite the fact that they are not valid anymore.
Part of MTRv1 is currently used in RQG semisync test, and this
was causing the test to fail on slave startup.
It should be safe to uncomment when merging up to celosia.
mysql-test/r/sp-error.result:
Update test case result.
mysql-test/t/dirty_close.test:
Dirty close does not work under embedded.
mysql-test/t/sp-error.test:
Use the specific error number so it won't catch
other non-fatal errors.
One statement that have more than one different tables to update with
autoinc columns just was marked as unsafe in mixed mode, so the unsafe
warning can't be produced in statement mode.
To fix the problem, mark the statement as unsafe in statement mode too.
mysql-test/extra/rpl_tests/rpl_insert_id.test:
The test case is updated due to the patch of bug#45827.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
The test result is updated due to the patch of bug#45827.
mysql-test/suite/binlog/r/binlog_unsafe.result:
Test result for bug#45827.
mysql-test/suite/binlog/t/binlog_unsafe.test:
Added test to verify if stmt that have more than one
different tables to update with autoinc columns will
produce unsafe warning
mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result:
The test result is updated due to the patch of bug#45827.
mysql-test/suite/rpl/t/rpl_trigger.test:
The test case is updated due to the patch of bug#45827.
mysql-test/suite/rpl/t/rpl_variables_stm.test:
The test case is updated due to the patch of bug#45827.
sql/sql_base.cc:
Reomved the 'set_current_stmt_binlog_row_based_if_mixed' function
for producing unsafe warnings by executing 'decide_logging_format'
function later in statement mode
The additional patch. That 'loadxml.test' failure was actually about our testing system,
not the code.
Firstly we need a new mysqltest command, wich i called 'send_eval'. So the expression
can be evaluated, then started in a parallel thread. We only have separane 'send' and
'eval' commands at the moment.
Then we need to add the waiting code after the 'KILL' to our test, so the thread will be killed
before the test goes further. The present 'reap' command doesn't handle the killed threads
well.
per-file comments:
client/mysqltest.cc
Bug#42520 killing load .. infile Assertion failed: ! is_set(), file .\sql_error.cc, line 8
The 'send_eval' command implemented.
mysql-test/r/loadxml.result
Bug#42520 killing load .. infile Assertion failed: ! is_set(), file .\sql_error.cc, line 8
test result updated.
mysql-test/t/loadxml.test
Bug#42520 killing load .. infile Assertion failed: ! is_set(), file .\sql_error.cc, line 8
test case added.
------------------------------------------------------------
revno: 2476.784.4
revision-id: sp1r-davi@moksha.local-20071008114751-46069
parent: sp1r-davi@moksha.local-20071003002731-48537
committer: davi@moksha.local
timestamp: Mon 2007-10-08 08:47:51 -0300
message:
Bug#27249 table_wild with alias: select t1.* as something
Aliases to table wildcards are silently ignored, but they should
not be allowed as it is non-standard and currently useless. There
is not point in having a alias to a wildcard of column names.
The solution is to rewrite the select_item rule so that aliases
for table wildcards are not accepted.
Contribution by Martin Friebe
mysql-test/r/alias.result:
Add test case result for Bug#27249
mysql-test/t/alias.test:
Add test case for Bug#27249
sql/sql_yacc.yy:
Split up select_item rule so that aliases for table wildcards
are not accepted by the parser.
------------------------------------------------------------
revno: 2597.4.17
revision-id: sp1r-davi@mysql.com/endora.local-20080328174753-24337
parent: sp1r-anozdrin/alik@quad.opbmk-20080328140038-16479
committer: davi@mysql.com/endora.local
timestamp: Fri 2008-03-28 14:47:53 -0300
message:
Bug#15192 "fatal errors" are caught by handlers in stored procedures
The problem is that fatal errors (e.g.: out of memory) were being
caught by stored procedure exception handlers which could cause
the execution to not be stopped due to a continue handler.
The solution is to not call any exception handler if the error is
fatal and send the fatal error to the client.
mysql-test/r/sp-error.result:
Add test case result for Bug#15192
mysql-test/t/sp-error.test:
Add test case for Bug#15192
mysys/my_alloc.c:
Pass flag to signal fatal error in memory root allocations.
sql/event_data_objects.cc:
Use init_sql_alloc to initialize memory roots, which uses
the sql error handler to push errors.
sql/ha_partition.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/item_func.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/item_subselect.cc:
Remove redundant fatal error, memory root already pushes error.
sql/opt_sum.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/sp_head.cc:
Allocator already sets fatal error.
sql/sql_class.h:
A error must exist for it to be fatal. Pass flag to signal fatal
error instead of calling fatal_error.
sql/sql_insert.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/sql_list.h:
Pass flag to signal fatal error instead of calling fatal_error.
sql/sql_parse.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/sql_partition.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/sql_select.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/sql_servers.cc:
Use init_sql_alloc to initialize memory roots, which uses
the sql error handler to push errors.
sql/sql_show.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/sql_trigger.cc:
Use init_sql_alloc to initialize memory roots, which uses
the sql error handler to push errors.
sql/sql_update.cc:
Pass flag to signal fatal error instead of calling fatal_error.
sql/tztime.cc:
Use init_sql_alloc to initialize memory roots, which uses
the sql error handler to push errors.
------------------------------------------------------------
revno: 3317
revision-id: davi.arnaut@sun.com-20090522170916-fzc5ca3tjs9roy1t
parent: patrick.crews@sun.com-20090522152933-ole8s3suy4zqyvku
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 41860-6.0
timestamp: Fri 2009-05-22 14:09:16 -0300
message:
Bug#41860: Without Windows named pipe
The problem was that the patch for Bug#10374 broke named pipe
and shared memory transports on Windows due to a failure to
implement a dummy poll method for transports other than BSD
sockets. Another problem was that mysqltest lacked support
for named pipe and shared memory connections, which lead to
misleading test cases that were supposed run common queries
over both transports.
The solution is to properly implement, at the VIO layer, the
poll and is_connected methods. The is_connected method is
implemented for every suppported transport and the poll one
only where it makes sense. Furthermore, support for named pipe
and shared memory connections is added to mysqltest as to
enable testing of both transports using the test suite.
client/mysqltest.cc:
Add support for named pipe and shared memory connections.
include/violite.h:
Move private functions to vio/vio_priv.h
Add poll_read and is_connected methods.
mysql-test/t/named_pipe.test:
Run tests over a named pipe connection.
mysql-test/t/shm.test:
Run tests over a shared memory connection.
sql/item_func.cc:
Rename method.
sql/sql_class.cc:
Remove higher-level vio_is_connected implementation.
sql/sql_class.h:
Rename vio_is_connected to not conflict with the vio one.
Verify that there is a valid vio.
vio/vio.c:
Add poll_read and is_connected methods.
vio/vio_priv.h:
Add private functions.
vio/viosocket.c:
Implement the is_connected method for the various transports.
------------------------------------------------------------
revno: 2597.37.3
revision-id: sp1r-davi@mysql.com/endora.local-20080328123626-16430
parent: sp1r-anozdrin/alik@quad.opbmk-20080327125300-11290
committer: davi@mysql.com/endora.local
timestamp: Fri 2008-03-28 09:36:26 -0300
message:
Bug#10374 GET_LOCK does not let connection to close on the server side if it's aborted
The problem is that the server doesn't detect aborted connections which
are waiting on a lock or sleeping (user sleep), wasting system resources
for a connection that is already dead.
The solution is to peek at the connection every five seconds to verify if
the connection is not aborted. A aborted connection is detect by polling
the connection socket for available data to be read or end of file and in
case of eof, the wait is aborted and the connection killed.
include/violite.h:
Export vio_peek_read function.
mysql-test/r/dirty_close.result:
Add test case result for Bug#10374
mysql-test/t/dirty_close.test:
Add test case for Bug#10374
sql/item_func.cc:
While waiting for a condition to be signaled, check if the connection
is not broken every INTERRUPT_INTERVAL seconds.
sql/sql_class.cc:
Add function which checks if the client connection was aborted.
sql/sql_class.h:
Add function prototype.
vio/viosocket.c:
Add poll and peek functions for Windows and Unix.
------------------------------------------------------------
revno: 2572.2.1
revision-id: sp1r-davi@mysql.com/endora.local-20080227225948-16317
parent: sp1r-anozdrin/alik@quad.-20080226165712-10409
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-02-27 19:59:48 -0300
message:
Bug#27525 table not found when using multi-table-deletes with aliases over several databas
Bug#30234 Unexpected behavior using DELETE with AS and USING
The multi-delete statement has a documented limitation that
cross-database multiple-table deletes using aliases are not
supported because it fails to find the tables by alias if it
belongs to a different database. The problem is that when
building the list of tables to delete from, if a database
name is not specified (maybe an alias) it defaults to the
name of the current selected database, making impossible to
to properly resolve tables by alias later. Another problem
is a inconsistency of the multiple table delete syntax that
permits ambiguities in a delete statement (aliases that refer
to multiple different tables or vice-versa).
The first step for a solution and proper implementation of
the cross-databse multiple table delete is to get rid of any
ambiguities in a multiple table statement. Currently, the parser
is accepting multiple table delete statements that have no obvious
meaning, such as:
DELETE a1 FROM db1.t1 AS a1, db2.t2 AS a1;
DELETE a1 AS a1 FROM db1.t1 AS a1, db2.t2 AS a1;
The solution is to resolve the left part of a delete statement
using the right part, if the a table on right has an alias,
it must be referenced in the left using the given alias. Also,
each table on the left side must match unambiguously only one
table in the right side.
mysql-test/r/delete.result:
Add test case result for Bug#27525 and Bug#21148
mysql-test/r/derived.result:
Update error.
mysql-test/suite/rpl/r/rpl_multi_delete2.result:
Update syntax.
mysql-test/suite/rpl/t/rpl_multi_delete2.test:
Update syntax.
mysql-test/t/delete.test:
Add test case for Bug#27525 and Bug#21148
mysql-test/t/derived.test:
Update statement error, alias is properly resolved now.
sql/sql_parse.cc:
Implement new algorithm for the resolution of alias in
a multiple table delete statement.
sql/sql_yacc.yy:
Rework multi-delete parser rules to not accept table alias
for the table source list.
sql/table.h:
Add flag to signal that the table has a alias set or
that fully qualified table name was given.
------------------------------------------------------------
revno: 2630.2.13
revision-id: davi@mysql.com-20080612190452-cx6h7rm557bcq7sa
parent: davi@mysql.com-20080611124915-csejwrxfdga9upho
committer: Davi Arnaut <davi@mysql.com>
branch nick: 36785-6.0
timestamp: Thu 2008-06-12 16:04:52 -0300
message:
Bug#36785: Wrong error message when group_concat() exceeds max length
The problem is that when ER_CUT_VALUE_GROUP_CONCAT is elevated
to a error, the message does not get updated with the number of
cut lines when group_concat() exceeds max length.
The solution is to modify the warning message to be more meaningful
by giving the number of the line that was cut and to issue the warning
for each line that is cut. This approach is inline with how other
per-row truncated data warnings are issued avoids violating the warning
internal interface.
mysql-test/suite/sys_vars/r/group_concat_max_len_func.result:
Update result to reflect the new warning message
sql/share/errmsg.txt:
Update warning message ER_CUT_VALUE_GROUP_CONCAT.
------------------------------------------------------------
revno: 2630.39.3
revision-id: davi.arnaut@sun.com-20081210215359-i876m4zgc2d6rzs3
parent: kostja@sun.com-20081208222938-9es7wl61moli71ht
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 36649-6.0
timestamp: Wed 2008-12-10 19:53:59 -0200
message:
Bug#36649: Condition area is not properly cleaned up after stored routine invocation
The problem is that the diagnostics area of a trigger is not
isolated from the area of the statement that caused the trigger
invocation. In MySQL terms, it means that warnings generated
during the execution of the trigger are not removed from the
"warning area" at the end of the execution.
Before this fix, the rules for MySQL message list life cycle (see
manual entry for SHOW WARNINGS) did not apply to statements
inside stored programs:
- The manual says that the list of messages is cleared by a
statement that uses a table (any table). However, such
statement, if run inside a stored program did not clear the
message list.
- The manual says that the list is cleared by a statement that
generates a new error or a warning, but this was not the case
with stored program statements either and is changed to be the
case as well.
In other words, after this fix, a statement has the same effect
on the message list regardless of whether it's executed inside a
stored program/sub-statement or not.
This introduces an incompatible change:
- before this fix, a, e.g. statement inside a trigger could
never clear the global warning list
- after this fix, a trigger that generates a warning or uses a
table, clears the global warning list
- however, when we leave a trigger or a function, the caller's
warning information is restored (see more on this below).
This change is not backward compatible as it is intended to make
MySQL behavior similar to the SQL standard behavior:
A stored function or trigger will get its own "warning area" (or,
in standard terminology, diagnostics area). At the beginning of
the stored function or trigger, all messages from the caller area
will be copied to the area of the trigger. During execution, the
message list will be cleared according to the MySQL rules
described on the manual (SHOW WARNINGS entry). At the end of the
function/trigger, the "warning area" will be destroyed along with
all warnings it contains, except that if the last statement of
the function/trigger generated messages, these are copied into
the "warning area" of the caller.
Consequently, statements that use a table or generate a warning
*will* clear warnings inside the trigger, but that will have no
effect to the warning list of the calling (outer) statement.
mysql-test/r/sp.result:
Fix test case results.
mysql-test/r/trigger.result:
Fix test case results.
mysql-test/t/sp.test:
Add test case for Bug#36649
mysql-test/t/trigger.test:
Add test case for Bug#36649
sql/sp_head.cc:
Emulate multiple warning areas -- one per stored program instance.
sql/sql_parse.cc:
Message list reset rules are the same for statements inside
or outside compound statements.
------------------------------------------------------------
revno: 3624
revision-id: jon.hauglid@sun.com-20090928163426-2lg1gofzz44xzzxf
parent: alik@sun.com-20090928050057-r0a62x9czr01q7oe
committer: Jon Olav Hauglid <jon.hauglid@sun.com>
branch nick: mysql-6.0-codebase-bugfixing-bug47304
timestamp: Mon 2009-09-28 18:34:26 +0200
message:
Bug #47304 Test main.mdl_sync fails on embedded server
The problem was that SHOW PROCESSLIST was trying to access
a thread that was not properly running and therefore had an
uninitialized mutex.
This patch explicitly resets thd->mysys_var after each embedded
server command to prevent the mutex from being accessed in an
illegal state.
The patch also re-enables lock_multi.test and mdl_sync.test for
embedded server as they had been disabled because of this bug.
