1. 28 Sep, 2010 1 commit
  2. 09 Jul, 2010 1 commit
  3. 07 Jul, 2010 1 commit
  4. 04 Jul, 2010 1 commit
    • Vasil Dimov's avatar
      Merge mysql-5.1-innodb -> mysql-5.1-security · 0b0c18a0
      Vasil Dimov authored
      Merge up to sunny.bains@oracle.com-20100625081841-ppulnkjk1qlazh82 .
      There are 8 more changesets in mysql-5.1-innodb, but PB2 shows a
      failure for a test added in one of them. If that is resolved quickly
      then those 8 more changesets will be merged too.
      0b0c18a0
  5. 02 Jul, 2010 8 commits
  6. 01 Jul, 2010 2 commits
    • Alexey Kopytov's avatar
      Automerge. · 988dc230
      Alexey Kopytov authored
      988dc230
    • Alexey Kopytov's avatar
      Bug#54667: Unnecessary signal handler redefinition · ac89d926
      Alexey Kopytov authored
      POSIX requires that a signal handler defined with sigaction()
      is not reset on delivering a signal unless SA_NODEFER or
      SA_RESETHAND is set. It is therefore unnecessary to redefine
      the handler on signal delivery on platforms where sigaction()
      is used without those flags.
      ac89d926
  7. 30 Jun, 2010 2 commits
    • Sergey Glukhov's avatar
      Bug#51431 Wrong sort order after import of dump file · a6220d82
      Sergey Glukhov authored
      The problem is that QUICK_SELECT_DESC behaviour depends
      on used_key_parts value which can be bigger than selected
      best_key_parts value if an engine supports clustered key.
      But used_key_parts is overwritten with best_key_parts
      value that prevents from correct selection of index
      access method. The fix is to preserve used_key_parts
      value for further use in QUICK_SELECT_DESC.
      a6220d82
    • Staale Smedseng's avatar
      Bug #53899 Wrong mysql_stmt_errno() after connection loss with · 3b3983a4
      Staale Smedseng authored
      automatic reconnect
      
      A client with automatic reconnect enabled will see the error
      message "Lost connection to MySQL server during query" if the
      connection is lost between mysql_stmt_prepare() and
      mysql_stmt_execute(). The mysql_stmt_errno() number, however,
      is 0 -- not the corresponding value 2013.
      
      This patch checks for the case where the prepared statement
      has been pruned due to a connection loss (i.e., stmt->mysql
      has been set to NULL) during a call to cli_advanced_command(),
      and avoids changing the last_errno to the result of the last
      reconnect attempt.
      3b3983a4
  8. 29 Jun, 2010 2 commits
  9. 28 Jun, 2010 5 commits
  10. 27 Jun, 2010 2 commits
    • Alfranio Correia's avatar
      353e1107
    • 's avatar
      The following statements support the CURRENT_USER() where a user is needed. · 899a1d69
      authored
      DROP USER 
      RENAME USER CURRENT_USER() ...
      GRANT ... TO CURRENT_USER()
      REVOKE ... FROM CURRENT_USER()
      ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged
      as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
      executes the log event, 'CURRENT_USER()' is expand to the user of slave 
      SQL thread, but SQL thread's user name always NULL. This breaks the replication.
      
      After this patch, session's user will be written into query log events 
      if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.
      899a1d69
  11. 26 Jun, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54360 Deadlock DROP/ALTER/CREATE DATABASE with open HANDLER · 9fa66b64
      Jon Olav Hauglid authored
      This deadlock happened if DROP DATABASE was blocked due to an open
      HANDLER table from a different connection. While DROP DATABASE
      is blocked, it holds the LOCK_mysql_create_db mutex. This results
      in a deadlock if the connection with the open HANDLER table tries
      to execute a CREATE/ALTER/DROP DATABASE statement as they all
      try to acquire LOCK_mysql_create_db.
      
      This patch makes this deadlock scenario very unlikely by closing and
      marking for re-open all HANDLER tables for which there are pending
      conflicing locks, before LOCK_mysql_create_db is acquired.
      However, there is still a very slight possibility that a connection
      could access one of these HANDLER tables between closing/marking for
      re-open and the acquisition of LOCK_mysql_create_db.
      
      This patch is for 5.1 only, a separate and complete fix will be
      made for 5.5+.
      
      Test case added to schema.test.
      9fa66b64
  12. 25 Jun, 2010 8 commits
  13. 24 Jun, 2010 6 commits