An error occurred fetching the project authors.
  1. 11 Nov, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that refactors global read lock implementation and fixes · 378cdc58
      Dmitry Lenev authored
      bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ
      LOCK" and bug #54673 "It takes too long to get readlock for
      'FLUSH TABLES WITH READ LOCK'".
      
      The first bug manifested itself as a deadlock which occurred
      when a connection, which had some table open through HANDLER
      statement, tried to update some data through DML statement
      while another connection tried to execute FLUSH TABLES WITH
      READ LOCK concurrently.
      
      What happened was that FTWRL in the second connection managed
      to perform first step of GRL acquisition and thus blocked all
      upcoming DML. After that it started to wait for table open
      through HANDLER statement to be flushed. When the first connection
      tried to execute DML it has started to wait for GRL/the second
      connection creating deadlock.
      
      The second bug manifested itself as starvation of FLUSH TABLES
      WITH READ LOCK statements in cases when there was a constant
      stream of concurrent DML statements (in two or more
      connections).
      
      This has happened because requests for protection against GRL
      which were acquired by DML statements were ignoring presence of
      pending GRL and thus the latter was starved.
      
      This patch solves both these problems by re-implementing GRL
      using metadata locks.
      
      Similar to the old implementation acquisition of GRL in new
      implementation is two-step. During the first step we block
      all concurrent DML and DDL statements by acquiring global S
      metadata lock (each DML and DDL statement acquires global IX
      lock for its duration). During the second step we block commits
      by acquiring global S lock in COMMIT namespace (commit code
      acquires global IX lock in this namespace).
      
      Note that unlike in old implementation acquisition of
      protection against GRL in DML and DDL is semi-automatic.
      We assume that any statement which should be blocked by GRL
      will either open and acquires write-lock on tables or acquires
      metadata locks on objects it is going to modify. For any such
      statement global IX metadata lock is automatically acquired
      for its duration.
      
      The first problem is solved because waits for GRL become
      visible to deadlock detector in metadata locking subsystem
      and thus deadlocks like one in the first bug become impossible.
      
      The second problem is solved because global S locks which
      are used for GRL implementation are given preference over
      IX locks which are acquired by concurrent DML (and we can
      switch to fair scheduling in future if needed).
      
      Important change:
      FTWRL/GRL no longer blocks DML and DDL on temporary tables.
      Before this patch behavior was not consistent in this respect:
      in some cases DML/DDL statements on temporary tables were
      blocked while in others they were not. Since the main use cases
      for FTWRL are various forms of backups and temporary tables are
      not preserved during backups we have opted for consistently
      allowing DML/DDL on temporary tables during FTWRL/GRL.
      
      Important change:
      This patch changes thread state names which are used when
      DML/DDL of FTWRL is waiting for global read lock. It is now
      either "Waiting for global read lock" or "Waiting for commit
      lock" depending on the stage on which FTWRL is.
      
      Incompatible change:
      To solve deadlock in events code which was exposed by this
      patch we have to replace LOCK_event_metadata mutex with
      metadata locks on events. As result we have to prohibit
      DDL on events under LOCK TABLES.
      
      This patch also adds extensive test coverage for interaction
      of DML/DDL and FTWRL.
      
      Performance of new and old global read lock implementations
      in sysbench tests were compared. There were no significant
      difference between new and old implementations.
      378cdc58
  2. 10 Nov, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#58057: 5.1 libmysql/libmysql.c unused variable/compile failure · 80246ac8
      Davi Arnaut authored
      Bug#57995: Compiler flag change build error on OSX 10.4: my_getncpus.c
      Bug#57996: Compiler flag change build error on OSX 10.5 : bind.c
      Bug#57994: Compiler flag change build error : my_redel.c
      Bug#57993: Compiler flag change build error on FreeBsd 7.0 : regexec.c
      Bug#57992: Compiler flag change build error on FreeBsd : mf_keycache.c
      Bug#57997: Compiler flag change build error on OSX 10.6: debug_sync.cc
      
      Fix assorted compiler generated warnings.
      80246ac8
  3. 18 Oct, 2010 1 commit
  4. 06 Oct, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c · 5f911fa8
      Davi Arnaut authored
      Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock
      
      - Incompatible change: truncate no longer resorts to a row by
      row delete if the storage engine does not support the truncate
      method. Consequently, the count of affected rows does not, in
      any case, reflect the actual number of rows.
      
      - Incompatible change: it is no longer possible to truncate a
      table that participates as a parent in a foreign key constraint,
      unless it is a self-referencing constraint (both parent and child
      are in the same table). To work around this incompatible change
      and still be able to truncate such tables, disable foreign checks
      with SET foreign_key_checks=0 before truncate. Alternatively, if
      foreign key checks are necessary, please use a DELETE statement
      without a WHERE condition.
      
      Problem description:
      
      The problem was that for storage engines that do not support
      truncate table via a external drop and recreate, such as InnoDB
      which implements truncate via a internal drop and recreate, the
      delete_all_rows method could be invoked with a shared metadata
      lock, causing problems if the engine needed exclusive access
      to some internal metadata. This problem originated with the
      fact that there is no truncate specific handler method, which
      ended up leading to a abuse of the delete_all_rows method that
      is primarily used for delete operations without a condition.
      
      Solution:
      
      The solution is to introduce a truncate handler method that is
      invoked when the engine does not support truncation via a table
      drop and recreate. This method is invoked under a exclusive
      metadata lock, so that there is only a single instance of the
      table when the method is invoked.
      
      Also, the method is not invoked and a error is thrown if
      the table is a parent in a non-self-referencing foreign key
      relationship. This was necessary to avoid inconsistency as
      some integrity checks are bypassed. This is inline with the
      fact that truncate is primarily a DDL operation that was
      designed to quickly remove all data from a table.
      5f911fa8
  5. 09 Aug, 2010 1 commit
    • Konstantin Osipov's avatar
      A fix for Bug#41158 "DROP TABLE holds LOCK_open during unlink()". · f8bfa328
      Konstantin Osipov authored
      Remove acquisition of LOCK_open around file system operations,
      since such operations are now protected by metadata locks.
      Rework table discovery algorithm to not require LOCK_open.
      
      No new tests added since all MDL locking operations are covered
      in lock.test and mdl_sync.test, and as long as these tests
      pass despite the increased concurrency, consistency must be
      unaffected.
      f8bfa328
  6. 27 Jul, 2010 1 commit
    • Konstantin Osipov's avatar
      A pre-requisite patch for the fix for Bug#52044. · ec2c3bf2
      Konstantin Osipov authored
      This patch also fixes Bug#55452 "SET PASSWORD is
      replicated twice in RBR mode".
      
      The goal of this patch is to remove the release of 
      metadata locks from close_thread_tables().
      This is necessary to not mistakenly release
      the locks in the course of a multi-step
      operation that involves multiple close_thread_tables()
      or close_tables_for_reopen().
      
      On the same token, move statement commit outside 
      close_thread_tables().
      
      Other cleanups:
      Cleanup COM_FIELD_LIST.
      Don't call close_thread_tables() in COM_SHUTDOWN -- there
      are no open tables there that can be closed (we leave
      the locked tables mode in THD destructor, and this
      close_thread_tables() won't leave it anyway).
      
      Make open_and_lock_tables() and open_and_lock_tables_derived()
      call close_thread_tables() upon failure.
      Remove the calls to close_thread_tables() that are now
      unnecessary.
      
      Simplify the back off condition in Open_table_context.
      
      Streamline metadata lock handling in LOCK TABLES 
      implementation.
      
      Add asserts to ensure correct life cycle of 
      statement transaction in a session.
      
      Remove a piece of dead code that has also become redundant
      after the fix for Bug 37521.
      ec2c3bf2
  7. 23 Jul, 2010 2 commits
  8. 08 Jul, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#34043: Server loops excessively in _checkchunk() when safemalloc is enabled · a10ae353
      Davi Arnaut authored
      Essentially, the problem is that safemalloc is excruciatingly
      slow as it checks all allocated blocks for overrun at each
      memory management primitive, yielding a almost exponential
      slowdown for the memory management functions (malloc, realloc,
      free). The overrun check basically consists of verifying some
      bytes of a block for certain magic keys, which catches some
      simple forms of overrun. Another minor problem is violation
      of aliasing rules and that its own internal list of blocks
      is prone to corruption.
      
      Another issue with safemalloc is rather the maintenance cost
      as the tool has a significant impact on the server code.
      Given the magnitude of memory debuggers available nowadays,
      especially those that are provided with the platform malloc
      implementation, maintenance of a in-house and largely obsolete
      memory debugger becomes a burden that is not worth the effort
      due to its slowness and lack of support for detecting more
      common forms of heap corruption.
      
      Since there are third-party tools that can provide the same
      functionality at a lower or comparable performance cost, the
      solution is to simply remove safemalloc. Third-party tools
      can provide the same functionality at a lower or comparable
      performance cost. 
      
      The removal of safemalloc also allows a simplification of the
      malloc wrappers, removing quite a bit of kludge: redefinition
      of my_malloc, my_free and the removal of the unused second
      argument of my_free. Since free() always check whether the
      supplied pointer is null, redudant checks are also removed.
      
      Also, this patch adds unit testing for my_malloc and moves
      my_realloc implementation into the same file as the other
      memory allocation primitives.
      a10ae353
  9. 31 May, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#53445: Build with -Wall and fix warnings that it generates · 5dec0c96
      Davi Arnaut authored
      Fix various mismatches between function's language linkage. Any
      particular function that is declared in C++ but should be callable
      from C must have C linkage. Note that function types with different
      linkages are also distinct. Thus, if a function type is declared in
      C code, it will have C linkage (same if declared in a extern "C"
      block).
      5dec0c96
  10. 07 May, 2010 1 commit
    • Konstantin Osipov's avatar
      Draft patch that fixes and a sketches test cases for: · 5ac769be
      Konstantin Osipov authored
      Bug#20837 Apparent change of isolation level during transaction,
      Bug#46527 COMMIT AND CHAIN RELEASE does not make sense,
      Bug#53343 completion_type=1, COMMIT/ROLLBACK AND CHAIN don't 
      preserve the isolation level
      Bug#53346 completion_type has strange effect in a stored 
      procedure/prepared statement
      
      Make thd->tx_isolation mean strictly "current transaction 
      isolation level"
      Make thd->variables.tx_isolation mean "current session isolation
      level".
      The current transaction isolation level is now established
      at transaction start. If there was a SET TRANSACTION
      ISOLATION LEVEL statement, the value is taken from it.
      Otherwise, the session value is used.
      A change in a session value, made while a transaction is active,
      whereas still allowed, no longer has any effect on the
      current transaction isolation level. This is an incompatible
      change.
      A change in a session isolation level, made while there is
      no active transaction, overrides SET TRANSACTION statement,
      if there was any.
      Changed the impelmentation to not look at @@session.completion_type
      in the parser, and thus fixed Bug#53346.
      Changed the parser to not allow AND NO CHAIN RELEASE,
      and thus fixed Bug#46527.
      Changed the transaction API to take the current transaction
      isolation level into account:
      - BEGIN/COMMIT now do preserve the current transaction
      isolation level if chaining is on.
      - implicit commit, XA COMMIT or XA ROLLBACK or autocommit don't.
      5ac769be
  11. 05 May, 2010 1 commit
  12. 14 Apr, 2010 1 commit
    • Sergey Vojtovich's avatar
      BUG#39053 - UNISTALL PLUGIN does not allow the storage engine · b89feb5b
      Sergey Vojtovich authored
                  to cleanup open connections
      
      It was possible to UNINSTALL storage engine plugin when binding
      between THD object and storage engine is still active (e.g. in
      the middle of transaction).
      
      To avoid unclean deactivation (uninstall) of storage engine plugin
      in the middle of transaction, additional storage engine plugin
      lock is acquired by thd_set_ha_data().
      
      If ha_data is not null and storage engine plugin was not locked
      by thd_set_ha_data() in this connection before, storage engine
      plugin gets locked.
      
      If ha_data is null and storage engine plugin was locked by
      thd_set_ha_data() in this connection before, storage engine
      plugin lock gets released.
      
      If handlerton::close_connection() didn't reset ha_data, server does
      it immediately after calling handlerton::close_connection().
      
      Note that this is just a framework fix, storage engines must switch
      to thd_set_ha_data() from thd_ha_data() if they want to see fit.
      b89feb5b
  13. 31 Mar, 2010 1 commit
    • Mats Kindahl's avatar
      WL#5030: Split and remove mysql_priv.h · e409d6f6
      Mats Kindahl authored
      This patch:
      
      - Moves all definitions from the mysql_priv.h file into
        header files for the component where the variable is
        defined
      - Creates header files if the component lacks one
      - Eliminates all include directives from mysql_priv.h
      - Eliminates all circular include cycles
      - Rename time.cc to sql_time.cc
      - Rename mysql_priv.h to sql_priv.h
      e409d6f6
  14. 30 Mar, 2010 1 commit
    • Mattias Jonsson's avatar
      Bug#51851: Server with SBR locks mutex twice on LOAD DATA · 864d6bc9
      Mattias Jonsson authored
      into partitioned MyISAM table
      
      Problem was that the ha_data structure was introduced in 5.1
      and only used for partitioning first, but with the intention
      of be of use for others engines as well, and when used by other
      engines it would clash if it also was partitioned.
      
      Solution is to move the partitioning specific data to a separate
      structure, with its own mutex (which is used for auto_increment).
      
      Also did rename PARTITION_INFO to PARTITION_STATS since there
      already exist a class named partition_info, also cleaned up
      some related variables.
      864d6bc9
  15. 17 Mar, 2010 1 commit
  16. 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
  17. 18 Jan, 2010 1 commit
  18. 07 Jan, 2010 1 commit
  19. 22 Dec, 2009 1 commit
    • Sergei Golubchik's avatar
      WL#4738 streamline/simplify @@variable creation process · ae2768ce
      Sergei Golubchik authored
      Bug#16565 mysqld --help --verbose does not order variablesBug#20413 sql_slave_skip_counter is not shown in show variables
      Bug#20415 Output of mysqld --help --verbose is incomplete
      Bug#25430 variable not found in SELECT @@global.ft_max_word_len;
      Bug#32902 plugin variables don't know their names
      Bug#34599 MySQLD Option and Variable Reference need to be consistent in formatting!
      Bug#34829 No default value for variable and setting default does not raise error
      Bug#34834 ? Is accepted as a valid sql mode
      Bug#34878 Few variables have default value according to documentation but error occurs  
      Bug#34883 ft_boolean_syntax cant be assigned from user variable to global var.
      Bug#37187 `INFORMATION_SCHEMA`.`GLOBAL_VARIABLES`: inconsistent status
      Bug#40988 log_output_basic.test succeeded though syntactically false.
      Bug#41010 enum-style command-line options are not honoured (maria.maria-recover fails)
      Bug#42103 Setting key_buffer_size to a negative value may lead to very large allocations 
      Bug#44691 Some plugins configured as MYSQL_PLUGIN_MANDATORY in can be disabled
      Bug#44797 plugins w/o command-line options have no disabling option in --help
      Bug#46314 string system variables don't support expressions
      Bug#46470 sys_vars.max_binlog_cache_size_basic_32 is broken
      Bug#46586 When using the plugin interface the type "set" for options caused a crash.
      Bug#47212 Crash in DBUG_PRINT in mysqltest.cc when trying to print octal number
      Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds
      Bug#49417 some complaints about mysqld --help --verbose output
      Bug#49540 DEFAULT value of binlog_format isn't the default value
      Bug#49640 ambiguous option '--skip-skip-myisam' (double skip prefix)
      Bug#49644 init_connect and \0
      Bug#49645 init_slave and multi-byte characters
      Bug#49646 mysql --show-warnings crashes when server dies
      ae2768ce
  20. 03 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · c43f894c
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2630.22.3
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 4284-6.0
      timestamp: Thu 2008-08-07 22:33:43 -0300
      message:
      WL#4284: Transactional DDL locking
      
      Make transaction management more modular through a new interface.
      
      The overall objective of this change is to provide groundwork
      for the design of transactional DDL locking by cleaning up the
      transaction high level API to better distinguish operations implicit
      and explicit, and single statement transaction from operations on
      the normal transaction.
      
      Having a a high-level interface for transaction management provides
      a better base for implementing transactional concepts that are not
      always tied to storage engines and also makes it easier to interect
      with other higher level modules of the server.
      c43f894c
  21. 01 Dec, 2009 2 commits
    • Konstantin Osipov's avatar
      Backport of: · 1523cea6
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2630.4.26
      committer: Konstantin Osipov <konstantin@mysql.com>
      branch nick: mysql-6.0-prelocked_mode-to-push
      timestamp: Fri 2008-06-06 23:19:04 +0400
      message:
        WL#3726: work on review comments.
        Remove thd->locked_tables. Always store MYSQL_LOCK instances in
        thd->lock.
        Rename thd->prelocked_mode to thd->locked_tables_mode.
        Use thd->locked_tables_mode to determine if we
        are under LOCK TABLES. Update the code to not assume that
        if thd->lock is set, LOCK TABLES mode is off.
        Review comments.
      1523cea6
    • Georgi Kodinov's avatar
  22. 30 Nov, 2009 2 commits
    • 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
    • Magne Mahre's avatar
      Bug #20837 Apparent change of isolation level during transaction · 8c24f5d1
      Magne Mahre authored
            
      SET TRANSACTION ISOLATION LEVEL is used to temporarily set
      the trans.iso.level for the next transaction.  After the
      transaction, the iso.level is (re-)set to value of the 
      session variable 'tx_isolation'.
      
      The bug is caused by setting the thd->variables.tx_isolation 
      field to the value of the session variable upon each
      statement commit.  It should only be set at the end of the
      full transaction.
      
      The fix has been to remove the setting of the variable in
      ha_autocommit_or_rollback if we're in a transaction, as it 
      will be correctly set in  either ha_rollback or 
      ha_commit_one_phase.  
      
      If, on the other hand, we're in  autocommit mode, tx_isolation 
      will be explicitly set here.
      8c24f5d1
  23. 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
  24. 23 Nov, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · 777c3034
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2630.13.2
      committer: Davi Arnaut <davi@sun.com>
      branch nick: WL4284-6.0
      timestamp: Thu 2008-07-03 18:26:51 -0300
      message:
      Remove unused USING_TRANSACTIONS macro which unnecessarily
      cumbers the code. This macro is a historical leftover and
      has no practical use since its unconditionally defined.
      777c3034
  25. 04 Nov, 2009 1 commit
    • Luis Soares's avatar
      BUG#48048: Deprecated constructs need removal in Betony · 6e068a9c
      Luis Soares authored
      NOTE: Backport of:
      
      bzr log -r revid:sp1r-serg@sergbook.mysql.com-20070505200319-38337
      ------------------------------------------------------------
      revno: 2469.263.4
      committer: serg@sergbook.mysql.com
      timestamp: Sat 2007-05-05 13:03:19 -0700
      message:
        Removing deprecated features:
        --master-XXX command-line options
        log_bin_trust_routine_creators
        table_type
        BACKUP TABLE ...
        RESTORE TABLE ...
        SHOW PLUGIN
        LOAD TABLE ... FROM MASTER
        LOAD DATA FROM MASTER
        SHOW INNODB STATUS
        SHOW MUTEX STATUS
        SHOW TABLE TYPES
        ... TIMESTAMP(N)
        ... TYPE=engine
        
        RESET SLAVE don't reset connection parameters anymore
        LOAD DATA: check opt_secure_file_priv before access(filename)
        improved WARN_DEPRECATED macro
      6e068a9c
  26. 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
  27. 28 Oct, 2009 1 commit
  28. 21 Oct, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of revno 2630.28.10, 2630.28.31, 2630.28.26, 2630.33.1, · d4632dff
      Konstantin Osipov authored
      2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
      2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
      some other minor revisions.
      
      This patch implements: 
      
      WL#4264 "Backup: Stabilize Service Interface" -- all the
      server prerequisites except si_objects.{h,cc} themselves (they can
      be just copied over, when needed).
      
      WL#4435: Support OUT-parameters in prepared statements.
      
      (and all issues in the initial patches for these two
      tasks, that were discovered in pushbuild and during testing).
      
      Bug#39519: mysql_stmt_close() should flush all data
      associated with the statement.
      
      After execution of a prepared statement, send OUT parameters of the invoked
      stored procedure, if any, to the client.
      
      When using the binary protocol, send the parameters in an additional result
      set over the wire.  When using the text protocol, assign out parameters to
      the user variables from the CALL(@var1, @var2, ...) specification.
      
      The following refactoring has been made:
        - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
        - A new Protocol::send_result_set_row() was introduced to incapsulate
          common functionality for sending row data.
        - Signature of Protocol::prepare_for_send() was changed: this operation
          does not need a list of items, the number of items is fully sufficient.
      
      The following backward incompatible changes have been made:
        - CLIENT_MULTI_RESULTS is now enabled by default in the client;
        - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
      d4632dff
  29. 15 Oct, 2009 1 commit
  30. 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
  31. 02 Oct, 2009 1 commit
    • He Zhenxing's avatar
      Backport BUG#41013 main.bootstrap coredumps in 6.0-rpl · c1e2b147
      He Zhenxing authored
      When a storage engine failed to initialize before allocated slot number,
      the slot number would be 0, and when later finalizing this plugin, it would
      accidentally unplug the storage engine currently uses slot 0.
      
      This patch fixed this problem by add a new macro value HA_SLOT_UNDEF to
      distinguish undefined slot number from slot 0.
      c1e2b147
  32. 26 Sep, 2009 1 commit
  33. 25 Sep, 2009 1 commit
    • Mats Kindahl's avatar
      Bug #47645: Segmentation fault when out of memory during handlerton initialization · 14cf09c1
      Mats Kindahl authored
      There is a missing check for memory allocation failure when allocating
      memory for the handlerton structure. If the handlerton init function
      tries to de-reference the pointer, it will cause a segmentation fault
      and crash the server.
      
      This patch fixes the problem by not calling the init function if memory
      allocation failed, and instead prints an informative error message and
      reports the error to the caller.
      14cf09c1
  34. 23 Sep, 2009 1 commit
  35. 10 Sep, 2009 2 commits
  36. 09 Sep, 2009 1 commit
    • Sergey Vojtovich's avatar
      BUG#45638 - Create temporary table with engine innodb fails · 16c57d90
      Sergey Vojtovich authored
      Create temporary InnoDB table fails on case insensitive
      filesystems, when lower_case_table_names is 2 (e.g. OS X)
      and temporary directory path contains upper case letters.
      
      The problem was that tmpdir prefix was converted to lower
      case when table was created, but was passed as is when
      table was opened.
      
      Fixed by leaving tmpdir prefix part intact.
      16c57d90