1. 13 Sep, 2007 1 commit
    • tnurnberg@mysql.com/sin.intern.azundris.com's avatar
      Bug #15327: configure: --with-tcp-port option being partially ignored · 3c6ca8d6
      make sure that if builder configured with a non-standard (!= 3306)
      default TCP port that value actually gets used throughout. if they
      didn't configure a value, assume "use a sensible default", which
      will be read from /etc/services or, failing that, from the factory
      default. That makes the order of preference
      - command-line option
      - my.cnf, where applicable
      - $MYSQL_TCP_PORT environment variable
      - /etc/services (unless configured --with-tcp-port)
      - default port (--with-tcp-port=... or factory default)
      3c6ca8d6
  2. 20 Jul, 2007 1 commit
  3. 19 Jul, 2007 3 commits
  4. 18 Jul, 2007 1 commit
  5. 17 Jul, 2007 5 commits
  6. 16 Jul, 2007 5 commits
  7. 15 Jul, 2007 1 commit
  8. 14 Jul, 2007 4 commits
  9. 13 Jul, 2007 7 commits
  10. 12 Jul, 2007 7 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
    • 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
    • thek@adventure.(none)'s avatar
      Merge kpettersson@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 825b5096
      thek@adventure.(none) authored
      into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
      825b5096
    • thek@adventure.(none)'s avatar
      Merge adventure.(none):/home/thek/Development/cpp/bug28249/my50-bug28249 · 2a5e7fe5
      thek@adventure.(none) authored
      into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
      2a5e7fe5
    • thek@adventure.(none)'s avatar
      Bug#28249 Query Cache returns wrong result with concurrent insert / certain lock · 8ee7e48d
      thek@adventure.(none) authored
      A race condition in the integration between MyISAM and the query cache code 
      caused the query cache to fail to invalidate itself on concurrently inserted
      data.
      
      This patch fix this problem by using the existing handler interface which, upon
      each statement cache attempt, compare the size of the table as viewed from the 
      cache writing thread and with any snap shot of the global table state. If the
      two sizes are different the global table size is unknown and the current
      statement can't be cached.
      8ee7e48d
  11. 11 Jul, 2007 3 commits
  12. 10 Jul, 2007 2 commits
    • tnurnberg@sin.intern.azundris.com's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint · 9b4c3d0d
      tnurnberg@sin.intern.azundris.com authored
      into  mysql.com:/home/tnurnberg/22540/50-22540
      9b4c3d0d
    • tsmith@sita.local's avatar
      NULL MERGE UP to 5.1. · ccea97fa
      tsmith@sita.local authored
      Apply innodb-5.0-* snapshots:  ss1489 and ss1547.
      
      Fixes:
      Bug#9709:  InnoDB inconsistensy causes "Operating System Error 32/33"
      Bug#22819: SHOW INNODB STATUS crashes the server with an assertion failure under high load
      Bug#25645: Assertion failure in file srv0srv.c
      Bug#27294: insert into ... select ... causes crash with innodb_locks_unsafe_for_binlog=1
      Bug#28138: indexing column prefixes produces corruption in InnoDB
      ccea97fa