1. 26 Jul, 2007 3 commits
  2. 25 Jul, 2007 5 commits
    • antony@pcg5ppc.xiphis.org's avatar
      Bug#29522 · c3578663
      antony@pcg5ppc.xiphis.org authored
        "log.cc:1448: failed assertion `mysql_bin_log.is_open() && rex_data->empty()'"
        When Federated's transaction support was disabled by bug29875,
        this assertion became unreproducable.
      c3578663
    • acurtis/antony@ltamd64.xiphis.org's avatar
      Merge xiphis.org:/anubis/antony/work/p2-bug25679.3 · 1f0f46e4
      acurtis/antony@ltamd64.xiphis.org authored
      into  xiphis.org:/anubis/antony/work/p2-bug25679.3.merge-5.1
      1f0f46e4
    • acurtis/antony@xiphis.org/ltamd64.xiphis.org's avatar
      Bug#25679 · fbcd70a4
        "Federated Denial of Service"
        Federated storage engine used to attempt to open connections within
        the ::create() and ::open() methods which are invoked while LOCK_open
        mutex is being held by mysqld. As a result, no other client sessions
        can open tables while Federated is attempting to open a connection.
        Long DNS lookup times would stall mysqld's operation and a rogue
        connection string which connects to a remote server which simply
        stalls during handshake can stall mysqld for a much longer period of
        time.
        This patch moves the opening of the connection much later, when the
        federated actually issues queries, by which time the LOCK_open mutex is
        no longer being held.
      fbcd70a4
    • svoj@april.(none)'s avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-5.1-engines · 5c83b14b
      svoj@april.(none) authored
      into  mysql.com:/home/svoj/devel/mysql/BUG29806/mysql-5.1-engines
      5c83b14b
    • svoj@mysql.com/april.(none)'s avatar
      BUG#29806 - binlog_innodb.test creates a server log · 3b18aae7
      svoj@mysql.com/april.(none) authored
      Stopping mysql server could result in an entry in mysql error
      file: "InnoDB: Error: MySQL is freeing a thd".
      
      This happened because InnoDB assumes that the server will never
      call external_lock(F_UNLCK) in case external_lock(READ/WRITE)
      failed.
      
      Prior to this patch we haven't had strict definition whether
      external_lock(F_UNLCK) must be called in case external_lock(READ/WRITE)
      fails.
      
      This patch states that we never call external_lock(F_UNLCK) in case
      external_lock(READ/WRITE) fails.
      3b18aae7
  3. 24 Jul, 2007 10 commits
  4. 22 Jul, 2007 3 commits
  5. 21 Jul, 2007 5 commits
  6. 20 Jul, 2007 14 commits