1. 01 Dec, 2009 3 commits
  2. 30 Nov, 2009 1 commit
  3. 26 Nov, 2009 1 commit
  4. 25 Nov, 2009 9 commits
  5. 24 Nov, 2009 7 commits
  6. 23 Nov, 2009 5 commits
    • Konstantin Osipov's avatar
    • Konstantin Osipov's avatar
      Backport of: · 7edfae4e
      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.
      7edfae4e
    • Konstantin Osipov's avatar
      Backport of: · 777c3034
      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.
      777c3034
    • Alexander Nozdrin's avatar
      bd646780
    • Konstantin Osipov's avatar
      Backport of: · 7e532b13
      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.
      7e532b13
  7. 21 Nov, 2009 3 commits
  8. 20 Nov, 2009 11 commits
    • Konstantin Osipov's avatar
      Backport the implementation of vio_pending from 6.0-codebase. · a2a437b7
      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.
      a2a437b7
    • Konstantin Osipov's avatar
      Backport the test case for Bug#31881 "A statement is not aborted immediately if an error · 9a104341
      Konstantin Osipov authored
       inside a stored routine" from 6.0-codebase.
      9a104341
    • Konstantin Osipov's avatar
      Backport of: · ef4bd979
      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.
      ef4bd979
    • Konstantin Osipov's avatar
    • Konstantin Osipov's avatar
      Backport of: · 5a78d2a7
      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.
      5a78d2a7
    • Konstantin Osipov's avatar
      Backport of: · 36ab5d79
      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.
      36ab5d79
    • Konstantin Osipov's avatar
      Backport of: · 1ee8a588
      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.
      1ee8a588
    • Konstantin Osipov's avatar
      Backport of: · 948ee7e5
      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.
      948ee7e5
    • Marc Alff's avatar
      22de5f4b
    • Vladislav Vaintroub's avatar
      merge · 134d5e3a
      Vladislav Vaintroub authored
      134d5e3a
    • Magne Mahre's avatar
      Enable test cases for Bug#6063 and Bug#7088. · 2564b504
      Magne Mahre authored
      2564b504