- 08 Dec, 2009 1 commit
-
-
Mikael Ronstrom authored
-
- 27 Nov, 2009 5 commits
-
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
- 26 Nov, 2009 2 commits
-
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
- 25 Nov, 2009 1 commit
-
-
Alexander Nozdrin authored
-
- 24 Nov, 2009 7 commits
-
-
Marc Alff authored
-
Alexander Nozdrin authored
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 3559 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: mysql-pe timestamp: Fri 2009-08-28 15:23:16 -0300 message: Break down a large and obnoxious "if" statement. Multiple "if" statements makes it easy to understand and follow the code (specially in a debugger).
-
Konstantin Osipov authored
No commit message
-
Konstantin Osipov authored
---------------------------------------------------------------------- ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0 Bug#32082 : definition of VOID in my_global.h conflicts with Windows SDK headers VOID macro is now removed. Its usage is replaced with void cast. In some cases, where cast does not make much sense (pthread_*, printf, hash_delete, my_seek), cast is ommited.
-
Mikael Ronstrom authored
-
Alexander Nozdrin authored
-
- 23 Nov, 2009 6 commits
-
-
Konstantin Osipov authored
-
Konstantin Osipov authored
------------------------------------------------------------- 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.
-
Mikael Ronstrom authored
-
Konstantin Osipov authored
------------------------------------------------------------ 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.
-
Alexander Nozdrin authored
-
Konstantin Osipov authored
------------------------------------------------------------ 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.
-
- 21 Nov, 2009 1 commit
-
-
Konstantin Osipov authored
------------------------------------------------------------ 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.
-
- 20 Nov, 2009 17 commits
-
-
Konstantin Osipov authored
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.
-
Konstantin Osipov authored
inside a stored routine" from 6.0-codebase.
-
Konstantin Osipov authored
------------------------------------------------------------ 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.
-
Konstantin Osipov authored
-
Konstantin Osipov authored
------------------------------------------------------------ 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.
-
Konstantin Osipov authored
------------------------------------------------------------ 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.
-
Konstantin Osipov authored
------------------------------------------------------------ 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.
-
Konstantin Osipov authored
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.
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Marc Alff authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Magne Mahre authored
-