1. 17 Jul, 2007 3 commits
  2. 16 Jul, 2007 16 commits
  3. 15 Jul, 2007 3 commits
  4. 14 Jul, 2007 9 commits
  5. 13 Jul, 2007 2 commits
  6. 12 Jul, 2007 7 commits
    • svoj@mysql.com/april.(none)'s avatar
      BUG#29464 - load data infile into table with big5 chinese fulltext index · c16c5db7
      svoj@mysql.com/april.(none) authored
                  hangs 100% cpu
      
      Moved a test case for BUG#29464 into fulltext3.test, since it requires big5
      character set.
      c16c5db7
    • svoj@mysql.com/april.(none)'s avatar
      BUG#29445 - match ... against () never returns · e11d75e4
      svoj@mysql.com/april.(none) authored
      Part 2:
      Searching fulltext index for a word with boolean mode truncation
      operator may cause infinite loop.
      
      The problem was that "smarter index merge" was used with "trunc-words",
      which must never happen.
      
      Affects 5.1 only.
      e11d75e4
    • kostja@bodhi.(none)'s avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 6c152b29
      kostja@bodhi.(none) authored
      into  bodhi.(none):/opt/local/work/mysql-5.0-runtime
      6c152b29
    • kostja@bodhi.(none)'s avatar
      Apply community contributed fix for Bug#13326 SQLPS statement logging is · 366b761f
      kostja@bodhi.(none) authored
      incomplete in 5.0 (and review fixes).
      
      When in 5.0.13 I introduced class Prepared_statement and methods
      ::prepare and ::execute, general logging was left out of this class.
      This was good for stored procedures, since in stored procedures
      we do not log sub-statements, but introduced a regression in case of SQL
      syntax for prepared statements, as previously we would log the actual
      statements to the log, and after the change we would log only
      COM_QUERY text.
      
      Restore the old behavior, but still suppress logging if inside a stored 
      procedure.
      
      Based on a community contributed patch from Vladimir Shebordaev.
      
      No test case since we do not have a mechanism to test output
      of the general log.
      366b761f
    • kostja@bodhi.(none)'s avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 675a4e8f
      kostja@bodhi.(none) authored
      into  bodhi.(none):/opt/local/work/mysql-5.0-26141-final
      675a4e8f
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#26141 mixing table types in trigger · 5ab4b6f1
      kostja@bodhi.(none) authored
      causes full table lock on innodb table.
      Also fixes Bug#28502 Triggers that update another innodb table 
      will block on X lock unnecessarily (duplciate).
      Code review fixes.
      
      Both bugs' synopses are misleading: InnoDB table is
      not X locked. The statements, however, cannot proceed concurrently, 
      but this happens due to lock conflicts for tables used in triggers,
      not for the InnoDB table. 
      
      If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
      AFTER INSERT, competing for different resources (e.g. two distinct
      MyISAM tables), then these two triggers would not be able to execute
      concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
      not be able to run concurrently. 
      The problem had other side-effects (see respective bug reports).
      
      This behavior was a consequence of a shortcoming of the pre-locking
      algorithm, which would not distinguish between different DML operations
      (e.g. INSERT and DELETE) and pre-lock all the tables
      that are used by any trigger defined on the subject table.
      
      The idea of the fix is to extend the pre-locking algorithm to keep track,
      for each table, what DML operation it is used for and not
      load triggers that are known to never be fired.
      5ab4b6f1
    • istruewing@chilla.local's avatar
      Merge chilla.local:/home/mydev/mysql-5.1-ateam · 0880e245
      istruewing@chilla.local authored
      into  chilla.local:/home/mydev/mysql-5.1-bug28810
      0880e245