1. 19 Jul, 2007 4 commits
  2. 18 Jul, 2007 3 commits
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28524. · 3f91aeda
      gshchepa/uchum@gleb.loc authored
      For each view the mysqldump utility creates a temporary table
      with the same name and the same columns as the view 
      in order to satisfy views that depend on this view.
      After the creation of all tables, mysqldump drops all
      temporary tables and creates actual views.
      However, --skip-add-drop-table and --compact flags disable
      DROP TABLE statements for those temporary tables. Thus, it was
      impossible to create the views because of existence of the
      temporary tables with the same names.
      3f91aeda
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #29325: create table overwrites .MYD file of other · 94535ca8
      gkodinov/kgeorge@magare.gmz authored
      table (datadir)
      Set errno when retunring an error in my_create_with_symlink.
      94535ca8
    • sergefp@mysql.com's avatar
      Mark deadcode for gcov · 4f579b8d
      sergefp@mysql.com authored
      4f579b8d
  3. 17 Jul, 2007 5 commits
  4. 16 Jul, 2007 5 commits
  5. 15 Jul, 2007 5 commits
  6. 14 Jul, 2007 9 commits
  7. 13 Jul, 2007 4 commits
  8. 12 Jul, 2007 5 commits
    • 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
    • evgen@moonbone.local's avatar
      Bug#29739: Incorrect time comparison in BETWEEN. · 1b1464ba
      evgen@moonbone.local authored
      Time values were compared by the BETWEEN function as strings. This led to a
      wrong result in cases when some of arguments are less than 100 hours and other
      are greater.
      
      Now if all 3 arguments of the BETWEEN function are of the TIME type then
      they are compared as integers.
      1b1464ba
    • 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