1. 30 Oct, 2007 1 commit
  2. 26 Oct, 2007 3 commits
  3. 25 Oct, 2007 1 commit
  4. 24 Oct, 2007 3 commits
  5. 23 Oct, 2007 3 commits
  6. 19 Oct, 2007 7 commits
  7. 18 Oct, 2007 9 commits
    • malff@lambda.hsd1.co.comcast.net.'s avatar
      Merge lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-base · 2d6fbbda
      malff@lambda.hsd1.co.comcast.net. authored
      into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge
      2d6fbbda
    • malff@lambda.hsd1.co.comcast.net.'s avatar
      Merge lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-base · 6fa35a5d
      malff@lambda.hsd1.co.comcast.net. authored
      into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge
      6fa35a5d
    • antony@pcg5ppc.xiphis.org's avatar
      Merge pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p1-bug31473.1 · 407f73c8
      antony@pcg5ppc.xiphis.org authored
      into  pcg5ppc.xiphis.org:/private/Network/Servers/anubis.xiphis.org/home/antony/work/p1-bug31473.1-merge-5.1-engines
      407f73c8
    • antony@pcg5ppc.xiphis.org's avatar
      Bug#31473 · f4a153c3
      antony@pcg5ppc.xiphis.org authored
        "CSV does not work with NULL value in datetime fields"
        Attempting to insert a row with a NULL value for a DATETIME field
        results in a CSV file which the storage engine cannot read.
        Don't blindly assume that "0" is acceptable for all field types,
        Since CSV does not support NULL, we find out from the field the
        default non-null value.
        Do not permit the creation of a table with a nullable columns.
      f4a153c3
    • davi@moksha.com.br's avatar
      Merge moksha.com.br:/Users/davi/mysql/bugs/21557-5.1 · 5a2e5cf2
      davi@moksha.com.br authored
      into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime
      5a2e5cf2
    • davi@moksha.com.br's avatar
      Post merge fix for Bug 21557 · a2aafb60
      davi@moksha.com.br authored
      a2aafb60
    • davi@moksha.com.br's avatar
      Merge moksha.com.br:/Users/davi/mysql/bugs/21557-5.1 · 3b44d6e8
      davi@moksha.com.br authored
      into  moksha.com.br:/Users/davi/mysql/mysql-5.1-runtime
      3b44d6e8
    • davi@moksha.com.br's avatar
      Bug#21557 entries in the general query log truncated at 1000 characters. · dd135211
      davi@moksha.com.br authored
      The general log write function (general_log_print) uses printf style
      arguments which need to be pre-processed, meaning that the all arguments
      are copied to a single buffer and the problem is that the buffer size is
      constant (1022 characters) but queries can be much larger then this.
      
      The solution is to introduce a new log write function that accepts a
      buffer and it's length as arguments. The function is to be used when
      a formatted output is not required, which is the case for almost all
      query write-to-log calls.
      
      This is a incompatible change with respect to the log format of prepared
      statements.
      dd135211
    • istruewing@stella.local's avatar
      Bug#31692 - binlog_killed.test crashes sometimes · 672290b0
      istruewing@stella.local authored
      The server crashed when a thread was killed while locking the
      general_log table at statement begin.
      
      The general_log table is handled like a performance schema table.
      The state of open tables is saved and cleared so that this table
      seems to be the only open one. Then this table is opened and locked.
      After writing, the table is closed and the open table state is
      restored. Before restoring, however, it is asserted that there is
      no current table open.
      
      After locking the table, mysql_lock_tables() checks if the thread
      was killed in between. If so, it unlocks the table and returns an
      error. open_ltable() just returns with the error and leaves closing
      of the table to close_thread_tables(), which is called at
      statement end.
      
      open_performance_schema_table() did not take this into account.
      It assumed that a failed open_ltable() would not leave an open
      table behind.
      
      Fixed by closing thread tables after open_ltable() and before
      restore_backup_open_tables_state() if the thread was killed.
      
      No test case. It requires correctly timed parallel execution.
      Since this bug was detected by the test suite, it seems
      dispensable to add another test.
      672290b0
  8. 17 Oct, 2007 13 commits