An error occurred fetching the project authors.
  1. 04 Feb, 2010 1 commit
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · 06e1a73a
      Konstantin Osipov authored
      Cherry-pick a fix Bug#37148 from next-mr, to preserve
      file ids of the added files, and ensure that all the necessary
      changes have been pulled.
      
      Since initially Bug#37148 was null-merged into 6.0,
      the changeset that is now being cherry-picked was likewise
      null merged into next-4284.
      
      Now that Bug#37148 has been reapplied to 6.0, try to make
      it work with next-4284. This is also necessary to be able
      to pull other changes from 5.1-rep into next-4284.
      
      To resolve the merge issues use this changeset applied
      to 6.0:
      revid:jperkin@sun.com-20091216103628-ylhqf7s6yegui2t9
      revno: 3776.1.1
      committer: He Zhenxing <zhenxing.he@sun.com>
      branch nick: 6.0-codebase-bugfixing
      timestamp: Thu 2009-12-17 17:02:50 +0800
      message:
        Fix merge problem with Bug#37148
      
      
      06e1a73a
  2. 01 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Implement new type-of-operation-aware metadata locks. · afd15c43
      Dmitry Lenev authored
      Add a wait-for graph based deadlock detector to the
      MDL subsystem.
      
      Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
      bug #37346 "innodb does not detect deadlock between update and
      alter table".
      
      The first bug manifested itself as an unwarranted abort of a
      transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
      statement, when this transaction tried to repeat use of a
      table, which it has already used in a similar fashion before
      ALTER started.
      
      The second bug showed up as a deadlock between table-level
      locks and InnoDB row locks, which was "detected" only after
      innodb_lock_wait_timeout timeout.
      
      A transaction would start using the table and modify a few
      rows.
      Then ALTER TABLE would come in, and start copying rows
      into a temporary table. Eventually it would stumble on
      the modified records and get blocked on a row lock.
      The first transaction would try to do more updates, and get
      blocked on thr_lock.c lock.
      This situation of circular wait would only get resolved
      by a timeout.
      
      Both these bugs stemmed from inadequate solutions to the
      problem of deadlocks occurring between different
      locking subsystems.
      
      In the first case we tried to avoid deadlocks between metadata
      locking and table-level locking subsystems, when upgrading shared
      metadata lock to exclusive one.
      Transactions holding the shared lock on the table and waiting for
      some table-level lock used to be aborted too aggressively.
      
      We also allowed ALTER TABLE to start in presence of transactions
      that modify the subject table. ALTER TABLE acquires
      TL_WRITE_ALLOW_READ lock at start, and that block all writes
      against the table (naturally, we don't want any writes to be lost
      when switching the old and the new table). TL_WRITE_ALLOW_READ
      lock, in turn, would block the started transaction on thr_lock.c
      lock, should they do more updates. This, again, lead to the need
      to abort such transactions.
      
      The second bug occurred simply because we didn't have any
      mechanism to detect deadlocks between the table-level locks
      in thr_lock.c and row-level locks in InnoDB, other than
      innodb_lock_wait_timeout.
      
      This patch solves both these problems by moving lock conflicts
      which are causing these deadlocks into the metadata locking
      subsystem, thus making it possible to avoid or detect such
      deadlocks inside MDL.
      
      To do this we introduce new type-of-operation-aware metadata
      locks, which allow MDL subsystem to know not only the fact that
      transaction has used or is going to use some object but also what
      kind of operation it has carried out or going to carry out on the
      object.
      
      This, along with the addition of a special kind of upgradable
      metadata lock, allows ALTER TABLE to wait until all
      transactions which has updated the table to go away.
      This solves the second issue.
      Another special type of upgradable metadata lock is acquired
      by LOCK TABLE WRITE. This second lock type allows to solve the
      first issue, since abortion of table-level locks in event of
      DDL under LOCK TABLES becomes also unnecessary.
      
      Below follows the list of incompatible changes introduced by
      this patch:
      
      - From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
        statements that acquire TL_WRITE_ALLOW_READ lock)
        wait for all transactions which has *updated* the table to
        complete.
      
      - From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
        (i.e. all statements which acquire TL_WRITE table-level lock) wait
        for all transaction which *updated or read* from the table
        to complete.
        As a consequence, innodb_table_locks=0 option no longer applies
        to LOCK TABLES ... WRITE.
      
      - DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
        statements or transactions which use tables being dropped or
        renamed, and instead wait for these transactions to complete.
      
      - Since LOCK TABLES WRITE now takes a special metadata lock,
        not compatible with with reads or writes against the subject table
        and transaction-wide, thr_lock.c deadlock avoidance algorithm
        that used to ensure absence of deadlocks between LOCK TABLES
        WRITE and other statements is no longer sufficient, even for
        MyISAM. The wait-for graph based deadlock detector of MDL
        subsystem may sometimes be necessary and is involved. This may
        lead to ER_LOCK_DEADLOCK error produced for multi-statement
        transactions even if these only use MyISAM:
      
        session 1:         session 2:
        begin;
      
        update t1 ...      lock table t2 write, t1 write;
                           -- gets a lock on t2, blocks on t1
      
        update t2 ...
        (ER_LOCK_DEADLOCK)
      
      - Finally,  support of LOW_PRIORITY option for LOCK TABLES ... WRITE
        was abandoned.
        LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
        priority as the usual LOCK TABLE ... WRITE.
        SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE  in
        the wait queue.
      
      - We do not take upgradable metadata locks on implicitly
        locked tables. So if one has, say, a view v1 that uses
        table t1, and issues:
        LOCK TABLE v1 WRITE;
        FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
        an error is produced.
        In order to be able to perform DDL on a table under LOCK TABLES,
        the table must be locked explicitly in the LOCK TABLES list.
      afd15c43
  3. 28 Jan, 2010 1 commit
    • Davi Arnaut's avatar
      Fix for compiler warnings: · b5d307e8
      Davi Arnaut authored
      Rename method as to not hide a base.
      Reorder attributes initialization.
      Remove unused variable.
      Rework code to silence a warning due to assignment used as truth value.
      b5d307e8
  4. 25 Jan, 2010 1 commit
  5. 24 Jan, 2010 1 commit
  6. 22 Jan, 2010 1 commit
  7. 19 Jan, 2010 1 commit
  8. 10 Dec, 2009 1 commit
  9. 09 Dec, 2009 1 commit
    • He Zhenxing's avatar
      BUG#45520 rpl_killed_ddl fails sporadically in pb2 · 9058e481
      He Zhenxing authored
      There are three issues that caused rpl_killed_ddl fails sporadically
      in pb2:
      
       1) thd->clear_error() was not called before create Query event
      if operation is executed successfully.
       2) DATABASE d2 might do exist because the statement to CREATE or
      ALTER it was killed
       3) because of bug 43353, kill the query that do DROP FUNCTION or
          DROP PROCEDURE can result in SP not found
      
      This patch fixed all above issues by:
       1) Called thd->clear_error() if the operation succeeded.
       2) Add IF EXISTS to the DROP DATABASE d2 statement
       3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.
      9058e481
  10. 02 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · bcae0d9b
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2630.10.1
      committer: Konstantin Osipov <konstantin@mysql.com>
      branch nick: mysql-6.0-lock-tables-tidyup
      timestamp: Wed 2008-06-11 15:49:58 +0400
      message:
        WL#3726, review fixes.
        Now that we have metadata locks, we don't need to keep a crippled
        TABLE instance in the table cache to indicate that a table is locked.
        Remove all code that used this technique. Instead, rely on metadata
        locks and use the standard open_table() and close_thread_table()
        to manipulate with the table cache tables.
        Removes a list of functions that have become unused (see the comment
        for sql_base.cc for details).
        Under LOCK TABLES, keep a TABLE_LIST instance for each table
        that may be temporarily closed. For that, implement an own class for
        LOCK TABLES mode, Locked_tables_list.
      
      This is a pre-requisite patch for WL#4144.
      This is not exactly a backport: there is no new 
      online ALTER table in Celosia, so the old alter table
      code was changed to work with the new table cache API.
      bcae0d9b
  11. 01 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · f198e8be
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2630.2.20
      committer: Konstantin Osipov <konstantin@mysql.com>
      branch nick: mysql-6.0-runtime
      timestamp: Fri 2008-06-27 20:10:42 +0400
      message:
        Fix a regression introduced by WL#3726 when a table was left in the
        table cache after DROP DATABASE.
        Implementation of DROP DATABASE reads a list of files in the database
        directory and constructs from it the list of tables to be dropped.
        If the filesystem is case-insensitive and case-preserving, the
        table names should be lowercased, because the same has been done
        when entries for them were inserted into the table cache.
        Skipping this step will lead to orphaned TABLEs left in the table cache.
        Fixes lowercase_table2 failure on powermacg5.
      f198e8be
  12. 30 Nov, 2009 1 commit
    • Konstantin Osipov's avatar
      Initial import of WL#3726 "DDL locking for all metadata objects". · 69b9761f
      Konstantin Osipov authored
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.1
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Fri 2008-05-23 17:54:03 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        After review fixes in progress.
      ------------------------------------------------------------
      
      This is the first patch in series. It transforms the metadata 
      locking subsystem to use a dedicated module (mdl.h,cc). No 
      significant changes in the locking protocol. 
      The import passes the test suite with the exception of 
      deprecated/removed 6.0 features, and MERGE tables. The latter
      are subject to a fix by WL#4144.
      Unfortunately, the original changeset comments got lost in a merge,
      thus this import has its own (largely insufficient) comments.
      
      This patch fixes Bug#25144 "replication / binlog with view breaks".
      Warning: this patch introduces an incompatible change:
      Under LOCK TABLES, it's no longer possible to FLUSH a table that 
      was not locked for WRITE.
      Under LOCK TABLES, it's no longer possible to DROP a table or
      VIEW that was not locked for WRITE.
      
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.2
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sat 2008-05-24 14:03:45 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        After review fixes in progress.
      
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.3
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sat 2008-05-24 14:08:51 +0400
      message:
        WL#3726 "DDL locking for all metadata objects"
      
        Fixed failing Windows builds by adding mdl.cc to the lists
        of files needed to build server/libmysqld on Windows.
      
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.4
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sat 2008-05-24 21:57:58 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        Fix for assert failures in kill.test which occured when one
        tried to kill ALTER TABLE statement on merge table while it
        was waiting in wait_while_table_is_used() for other connections
        to close this table.
      
        These assert failures stemmed from the fact that cleanup code
        in this case assumed that temporary table representing new
        version of table was open with adding to THD::temporary_tables
        list while code which were opening this temporary table wasn't
        always fulfilling this.
      
        This patch changes code that opens new version of table to
        always do this linking in. It also streamlines cleanup process
        for cases when error occurs while we have new version of table
        open.
      
      ******
      WL#3726 "DDL locking for all metadata objects"
      Add libmysqld/mdl.cc to .bzrignore.
      ******
      Backport of:
      ------------------------------------------------------------
      revno: 2630.4.6
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Sun 2008-05-25 00:33:22 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        Addition to the fix of assert failures in kill.test caused by
        changes for this worklog.
      
      
      Make sure we close the new table only once.
      69b9761f
  13. 24 Nov, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · 4cff617c
      Konstantin Osipov authored
      ----------------------------------------------------------------------
      ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0
        Bug#32082 : definition of VOID in my_global.h conflicts with Windows
        SDK headers
        
        VOID macro is now removed. Its usage is replaced with void cast.
        In some cases, where cast does not make much sense (pthread_*, printf, 
        hash_delete, my_seek), cast is ommited.
      4cff617c
  14. 21 Nov, 2009 1 commit
    • He Zhenxing's avatar
      BUG#37148 Most callers of mysql_bin_log.write ignore the return result · 9b65f578
      He Zhenxing authored
      This is the non-ndb part of the patch.
      
      The return value of mysql_bin_log.write was ignored by most callers,
      which may lead to inconsistent on master and slave if the transaction
      was committed while the binlog was not correctly written. If
      my_error() is call in mysql_bin_log.write, this could also lead to
      assertion issue if my_ok() or my_error() is called after.
      
      This fixed the problem by let the caller to check and handle the
      return value of mysql_bin_log.write. This patch only adresses the
      simple cases.
      9b65f578
  15. 03 Nov, 2009 1 commit
    • Alfranio Correia's avatar
      WL#2687 WL#5072 BUG#40278 BUG#47175 · 60d46624
      Alfranio Correia authored
      Non-transactional updates that take place inside a transaction present problems
      for logging because they are visible to other clients before the transaction
      is committed, and they are not rolled back even if the transaction is rolled
      back. It is not always possible to log correctly in statement format when both
      transactional and non-transactional tables are used in the same transaction.
      
      In the current patch, we ensure that such scenario is completely safe under the
      ROW and MIXED modes.
      60d46624
  16. 16 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40877: multi statement execution fails in 5.1.30 · 8f6f3dba
      Georgi Kodinov authored
            
      Implemented the server infrastructure for the fix:
      
      1. Added a function LEX_STRING *thd_query_string(THD) to return
      a LEX_STRING structure instead of char *.
      This is the function that must be called in innodb instead of 
      thd_query()
      
      2. Did some encapsulation in THD : aggregated thd_query and 
      thd_query_length into a LEX_STRING and made accessor and mutator 
      methods for easy code updating. 
      
      3. Updated the server code to use the new methods where applicable.
      8f6f3dba
  17. 14 Oct, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · 64dbe379
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2617.22.5
      committer: Konstantin Osipov <kostja@sun.com>
      branch nick: mysql-6.0-runtime
      timestamp: Tue 2009-01-27 05:08:48 +0300
      message:
        Remove non-prefixed use of HASH.
        Always use my_hash_init(), my_hash_inited(), my_hash_search(),
        my_hash_element(), my_hash_delete(), my_hash_free() rather
        than non-prefixed counterparts (hash_init(), etc).
        Remove the backward-compatible defines.
      64dbe379
  18. 07 Oct, 2009 1 commit
    • Alexander Nozdrin's avatar
      A backport of patch for Bug#26704. · 104efe86
      Alexander Nozdrin authored
      Original revision is from mysql-6.0-codebase:
      
      revno: 2630.3.1
      committer: Alexander Nozdrin <alik@mysql.com>
      branch nick: 6.0-rt-bug26704
      timestamp: Thu 2008-05-29 21:04:06 +0400
      message:
        A fix for Bug#26704: Failing DROP DATABASE brings
        mysql-client out of sync.
      
        The problem was that we changed current database w/o caring
        whether it was dropped successfully or not.
      
        The fix is not to change current database if we failed to drop it.
      104efe86
  19. 23 Sep, 2009 1 commit
  20. 17 Sep, 2009 1 commit
  21. 13 Aug, 2009 1 commit
    • 's avatar
      BUG#45574 CREATE IF NOT EXISTS is not binlogged if the object exists · 10e90a1f
      authored
      There is an inconsistency with DROP DATABASE|TABLE|EVENT IF EXISTS and
      CREATE DATABASE|TABLE|EVENT IF NOT EXISTS. DROP IF EXISTS statements are
      binlogged even if either the DB, TABLE or EVENT does not exist. In
      contrast, Only the CREATE EVENT IF NOT EXISTS is binlogged when the EVENT
      exists.  
      
      This patch fixes the following cases for all the replication formats:
      CREATE DATABASE IF NOT EXISTS.
      CREATE TABLE IF NOT EXISTS,
      CREATE TABLE IF NOT EXISTS ... LIKE,
      CREAET TABLE IF NOT EXISTS ... SELECT.
      10e90a1f
  22. 19 Jun, 2009 1 commit
  23. 30 May, 2009 1 commit
  24. 27 Mar, 2009 1 commit
    • He Zhenxing's avatar
      BUG#37145 Killing a statement doing DDL may log binlog event with error code 1053 · 95301268
      He Zhenxing authored
      When the thread executing a DDL was killed after finished its
      execution but before writing the binlog event, the error code in
      the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or
      ER_QUERY_INTERRUPTED.
      
      This patch fixed the problem by ignoring the kill status when
      constructing the event for DDL statements.
      
      This patch also included the following changes in order to
      provide the test case.
      
       1) modified mysqltest to support variable for connection command
      
       2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to
          run mysql client against the slave mysqld.
      95301268
  25. 10 Feb, 2009 1 commit
  26. 12 Jan, 2009 1 commit
    • Joerg Bruehe's avatar
      Backport of a 5.0.74 fix into 5.0.72sp1: · 505df896
      Joerg Bruehe authored
      Bug #40021: Renaming view fails, archived .frm for view is
                  missing after downgrade
      
      Original changeset:
      > revision-id: gshchepa@mysql.com-20081114172557-xh0jlzwal8ze3cy6
      > parent: ramil@mysql.com-20081114074229-vj4fvfrpmz8jfub9
      > committer: Gleb Shchepa <gshchepa@mysql.com>
      > branch nick: mysql-5.0-bugteam
      > timestamp: Fri 2008-11-14 21:25:57 +0400
      505df896
  27. 14 Nov, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #40021: Renaming view fails, archived .frm for view is · b82094a0
      Gleb Shchepa authored
                  missing after downgrade
      
      Obsolete arc/ directory and view .frm file backup support
      has been removed by the patch for bug 17823. However, that
      bugfix caused a problem with "live downgrades" of the
      server: if we rename some view 4 times under 5.1.29/5.0.72
      and then try to rename it under 5.1.28/5.0.70 on the same
      database, the server fails with a error:
      
        query 'RENAME TABLE ... TO ...' failed: 6: Error on
        delete of '....frm-0001' (Errcode: 2)
      
      Also .frm file of that view may be lost (renamed to .frm~).
      
      The server failed because it tried to rename latest 3
      backup .frm files renaming the view: the server used an
      integer value of the "revision" field of .frm file to
      extract those file names. After the fix for bug 17823 those
      files were not created/maintained any more, however the
      "revision" field was incremented as usual. So, the server
      failed renaming non existent files.
      
      This fix solves the problem by removing the support for
      "revision" .frm file field:
      1. New server silently ignores existent "revision" fields
         in old .frm files and never write it down;
      2. Old server assumes, that missing "revision" field in new
         .frm files means default value of 0.
      3. Accordingly to the fix for bug 17823 the new server
         drops arc/ directory on alter/rename view, so after
         "live downgrade" old server begins maintenance of the
         arc/ directory from scratch without conflicts with .frm
         files.
      b82094a0
  28. 30 Sep, 2008 1 commit
    • Gleb Shchepa's avatar
      Fixed bug #17823: 'arc' directories inside database directories. · e20b9de1
      Gleb Shchepa authored
      Server created "arc" directories inside database directories and
      maintained there useless copies of .frm files.
      
      Creation and renaming procedures of those copies as well as
      creation of "arc" directories has been discontinued.
      Removal procedure has been kept untouched to be able to
      cleanup existent database directories by the DROP DATABASE
      query. Also view renaming procedure has been updated to remove
      these directories.
      e20b9de1
  29. 27 Aug, 2008 1 commit
    • Mats Kindahl's avatar
      Bug #38773: DROP DATABASE cause switch to stmt-mode when there are temporary · 64610898
      Mats Kindahl authored
                  tables open
      
      When executing a DROP DATABASE statement in ROW mode and having temporary
      tables open at the same time, the existance of temporary tables prevent
      the server from switching back to row mode after temporarily switching to
      statement mode to handle the logging of the statement.
      
      Fixed the problem by removing the code to switch to statement mode and added
      code to temporarily disable the binary log while dropping the objects in the
      database.
      64610898
  30. 20 Aug, 2008 1 commit
    • Mats Kindahl's avatar
      Bug #38773: DROP DATABASE cause switch to stmt-mode when there are temporary tables open · 1bfa707a
      Mats Kindahl authored
      When executing a DROP DATABASE statement in ROW mode and having temporary
      tables open at the same time, the existance of temporary tables prevent
      the server from switching back to row mode after temporarily switching to
      statement mode to handle the logging of the statement.
      
      Fixed the problem by removing the code to switch to statement mode and added
      code to temporarily disable the binary log while dropping the objects in the
      database.
      1bfa707a
  31. 09 May, 2008 1 commit
  32. 21 Mar, 2008 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #26461: Intrinsic data type bool (1 byte) redefined to BOOL (4 bytes) · ff0aac17
      gkodinov/kgeorge@macbook.gmz authored
      The bool data type was redefined to BOOL (4 bytes on windows).
      Removed the #define and fixed some of the warnings that were uncovered
      by this.
      Note that the fix also disables 2 warnings :
      4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning)
      4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation
      
      These warnings will be handled in a separate bug, as they are performance related or bogus.
      
      Fixed to int the return type of functions that return more than 
      2 distinct values.
      ff0aac17
  33. 12 Mar, 2008 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#26703: DROP DATABASE fails if database contains a #mysql50# \ · 05258bfa
      cmiller@zippy.cornsilk.net authored
      	table with backticks
      
      (Thanks to Lu Jingdong, though I did not take his patch directly, as
      it contained a significant flaw.)
      
      It wasn't a backtick/parsing problem.  We merely didn't anticipate
      and allocate enough space to handle the optional "#mysql50#" table-
      name prefix. 
      
      Now, allocate that extra space in case we need it when we look up 
      a legacy table to get its file's name.
      05258bfa
  34. 19 Feb, 2008 1 commit
  35. 12 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Bug#12713 "Error in a stored function called from a SELECT doesn't · ebb9c5d9
      kostja@bodhi.(none) authored
      cause ROLLBACK of statement", part 1. Review fixes.
      
      Do not send OK/EOF packets to the client until we reached the end of 
      the current statement.
      This is a consolidation, to keep the functionality that is shared by all 
      SQL statements in one place in the server.
      Currently this functionality includes:
      - close_thread_tables()
      - log_slow_statement().
      
      After this patch and the subsequent patch for Bug#12713, it shall also include:
      - ha_autocommit_or_rollback()
      - net_end_statement()
      - query_cache_end_of_result().
      
      In future it may also include:
      - mysql_reset_thd_for_next_command().
      ebb9c5d9
  36. 26 Nov, 2007 1 commit
  37. 23 Nov, 2007 1 commit
  38. 16 Nov, 2007 1 commit
    • mkindahl@dl145h.mysql.com's avatar
      Bug#32435: · e0ae1050
      mkindahl@dl145h.mysql.com authored
      DROP DATABASE statement writes changes to mysql.proc table under RBR
      
      When replicating a DROP DATABASE statement with a database holding
      stored procedures, the changes to the mysql.proc table was recorded
      in the binary log under row-based replication.
      
      With this patch, the thread uses statement-logging format for the
      duration of the DROP DATABASE statement. The logging format is
      (already) reset at the end of the statement, so no additional code
      for resetting the logging format is necessary.
      e0ae1050
  39. 10 Sep, 2007 1 commit
  40. 31 Aug, 2007 1 commit
    • anozdrin/alik@ibm.opbmk's avatar
      Fix for BUG#25843: changing default database between PREPARE and EXECUTE · d6f94b06
      anozdrin/alik@ibm.opbmk authored
      of statement breaks binlog.
      
      There were two problems discovered by this bug:
      
        1. Default (current) database is not fixed at the creation time.
           That leads to wrong output of DATABASE() function.
      
        2. Database attributes (@@collation_database) are not fixed at
           the creation time. That leads to wrong resultset.
      
      Binlog breakage and Query Cache wrong output happened because of
      the first problem.
      
      The fix is to remember the current database at the PREPARE-time and
      set it each time at EXECUTE.
      d6f94b06