-------------------------------------------------------------
revno: 2877
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 35164-6.0
timestamp: Wed 2008-10-15 19:53:18 -0300
message:
Bug#35164: Large number of invalid pthread_attr_setschedparam calls
Bug#37536: Thread scheduling causes performance degradation at low thread count
Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows
The problem is that although having threads with different priorities
yields marginal improvements [1] in some platforms [2], relying on some
statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well
(or to work at all) with different scheduling practices and disciplines
is, at best, a shot in the dark as the meaning of priority values may
change depending on the scheduling policy set for the process.
Another problem is that increasing priorities can hurt other concurrent
(running on the same hardware) applications (such as AMP) by causing
starvation problems as MySQL threads will successively preempt lower
priority processes. This can be evidenced by Bug#12702.
The solution is to not change the threads priorities and rely on the
system scheduler to perform its job. This also enables a system admin
to increase or decrease the scheduling priority of the MySQL process,
if intended.
Furthermore, the internal wrappers and code for changing the priority
of threads is being removed as they are now unused and ancient.
1. Due to unintentional side effects. On Solaris this could artificially
help benchmarks as calling the priority changing syscall millions of
times is more beneficial than the actual setting of the priority.
2. Where it actually works. It has never worked on Linux as the default
scheduling policy SCHED_OTHER only accepts the static priority 0.
------------------------------------------------------------
revno: 2630.13.2
committer: Davi Arnaut <davi@sun.com>
branch nick: WL4284-6.0
timestamp: Thu 2008-07-03 18:26:51 -0300
message:
Remove unused USING_TRANSACTIONS macro which unnecessarily
cumbers the code. This macro is a historical leftover and
has no practical use since its unconditionally defined.
------------------------------------------------------------
revno: 2642
committer: davi@mysql.com/endora.local
timestamp: Fri 2008-05-16 01:29:09 -0300
message:
Fix for a valgrind warning due to a jump on a uninitialized
variable. The problem was that the sql profile preparation
function wasn't being called for all possible code paths
of query execution. The solution is to move the preparation
to the dispatch_command function and to explicitly call the
profile preparation function on bootstrap.
beyond unsigned long.
BUG#44779: binlog.binlog_max_extension may be causing failure on
next test in PB
NOTE1: this is the backport to next-mr.
NOTE2: already includes patch for BUG#44779.
Binlog file extensions would turn into negative numbers once the
variable used to hold the value reached maximum for signed
long. Consequently, incrementing value to the next (negative) number
would lead to .000000 extension, causing the server to fail.
This patch addresses this issue by not allowing negative extensions
and by returning an error on find_uniq_filename, when the limit is
reached. Additionally, warnings are printed to the error log when the
limit is approaching. FLUSH LOGS will also report warnings to the
user, if the extension number has reached the limit. The limit has been
set to 0x7FFFFFFF as the maximum.
------------------------------------------------------------
revno: 2627
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-04-23 13:25:02 -0300
message:
Fix for a build failure on Windows due to ssize_t
not being declared.
Original changeset:
------------------------------------------------------------
revno: 2626
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-04-23 09:33:25 -0300
message:
Fix for main.ssl and main.ssl_compress test case failures under pool-of-threads.
The problem is that the SSL layer has a read buffer and might read
more data than requested by the VIO layer. The SSL layer empties the
socket buffer which causes the socket to not be signaled for IO if
the client is waiting for a command which is sitting in the read
buffer.
The solution is to retrieve from the transport layer the number of
bytes waiting in the read buffer. The data in the read buffer needs
to be processed before waiting for more data.
------------------------------------------------------------
revno: 2597.42.4
committer: davi@mysql.com/endora.local
timestamp: Tue 2008-04-15 17:29:42 -0300
message:
Bug#36004 mysql_stmt_prepare resets the list of warnings
Although the manual says that "the list of messages is reset
for each new statement that uses a table", the list of messages
is being unconditionally reset for prepare commands.
The solution is to enforce that the prepare command will only
reset the message list if the statement being prepared uses
a table or a warning is pushed.
------------------------------------------------------------
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.
------------------------------------------------------------
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.
revno: 2476.784.2
committer: davi@moksha.local
timestamp: Thu 2007-09-27 16:56:27 -0300
message:
Bug#28870 check that table locks are released/reset
The problem is that some mysql_lock_tables error paths are not
resetting the tables lock type back to TL_UNLOCK. If the lock
types are not reset properly, a table might be returned to the
table cache with wrong lock_type.
The proposed fix is to ensure that the tables lock type is always
properly reset when mysql_lock_tables fails. This is a
incompatible change with respect to the process state information.
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.
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.
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.
Just change mysql_foo to mysql_cv_foo for one cache-id variable name. There
was only one bad variable name, present in 5.0 and 5.1, but not in the -pe
branch.
Backported to 5.6.0 (mysql-next-mr-runtime)
STRING_RESULT argument
There is a "magic" number for precision : NOT_FIXED_DEC.
This means that the precision is not a fixed number.
But this constant was re-defined in several files and
was not available to the UDF developers.
Moved the NOT_FIXED_DEC definition to the correct header
and removed the redundant definitions.
Backported to 5.6.0 (mysql-next-mr-runtime)
(From: gkodinov)
Use and int * where possible to scan for trailing space in a
string instead of always iterating char-by-char.
Using the attached benchmark file on a 32 bit Intel Core 2
Duo CPU I've got 43485 ms run with the fix compared to 44373
without it.
Backported to 5.6.0 (next-mr-runtime)
6.0-codebase revid: 2476.1362.1
In fact this crashes in normal (not embedded) run also.
The problem is in the memory mapping. Handling the ha_myisammrg::extra(MMAP)
the MERGE engine tries to mmap all the tables it unites.
Though some can be empty and then in the mi_dynmap_file()
we call the my_mmap(0). Normally this call returns MAP_FAILED,
but not on FreeBSD. There it returns like a 'normal' value,
and after the consequitive munmap systems gets unstable and
crashes on some system call later.
per-file comments:
storage/myisam/mi_dynrec.c
Bug #47139 Test "merge" crashes in "embedded" run
don't try to mmap zero-length area, just return at once.
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.
