An error occurred fetching the project authors.
  1. 15 Nov, 2010 1 commit
    • Jorgen Loland's avatar
      Bug#54812: assert in Diagnostics_area::set_ok_status · 4bfd2121
      Jorgen Loland authored
                 during EXPLAIN
      
      Before the patch, send_eof() of some subclasses of 
      select_result (e.g., select_send::send_eof()) could 
      handle being called after an error had occured while others 
      could not. The methods that were not well-behaved would trigger
      an ASSERT on debug builds. Release builds were not affected.
      
      Consider the following query as an example for how the ASSERT
      could be triggered:
      
      A user without execute privilege on f() does
         SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1;
      resulting in "ERROR 42000: execute command denied to user..." 
      
      The server would end the query by calling send_eof(). The 
      fact that the error had occured would make the ASSERT trigger. 
      
      select_dumpvar::send_eof() was the offending method in the
      bug report, but the problem also applied to other 
      subclasses of select_result. This patch uniforms send_eof() 
      of all subclasses of select_result to handle being called 
      after an error has occured. 
      4bfd2121
  2. 13 Nov, 2010 1 commit
    • Alexander Nozdrin's avatar
      Fix for Bug#56934 (mysql_stmt_fetch() incorrectly fills MYSQL_TIME · 5af51e4a
      Alexander Nozdrin authored
      structure buffer).
      
      This is a follow-up for WL#4435. The bug actually existed not only
      MYSQL_TYPE_DATETIME type. The problem was that Item_param::set_value()
      was written in an assumption that it's working with expressions, i.e.
      with basic data types.
      
      There are two different quick fixes here:
        a) Change Item_param::make_field() -- remove setting of
           Send_field::length, Send_field::charsetnr, Send_field::flags and
           Send_field::type.
      
           That would lead to marshalling all data using basic types to the client
           (MYSQL_TYPE_LONGLONG, MYSQL_TYPE_DOUBLE, MYSQL_TYPE_STRING and
           MYSQL_TYPE_NEWDECIMAL). In particular, that means, DATETIME would be
           sent as MYSQL_TYPE_STRING, TINYINT -- as MYSQL_TYPE_LONGLONG, etc.
      
           That could be Ok for the client, because the client library does
           reverse conversion automatically (the client program would see DATETIME
           as MYSQL_TIME object). However, there is a problem with metadata --
           the metadata would be wrong (misleading): it would say that DATETIME is
           marshaled as MYSQL_TYPE_DATETIME, not as MYSQL_TYPE_STRING.
      
        b) Set Item_param::param_type properly to actual underlying field type.
           That would lead to double conversion inside the server: for example,
           MYSQL_TIME-object would be converted into STRING-object
           (in Item_param::set_value()), and then converted back to MYSQL_TIME-object
           (in Item_param::send()).
      
           The data however would be marshalled more properly, and also metadata would
           be correct.
      
      This patch implements b).
      
      There is also a possibility to avoid double conversion either by clonning
      the data field, or by storing a reference to it and using it on Item::send()
      time. That requires more work and might be done later.
      5af51e4a
  3. 28 Sep, 2010 1 commit
    • smenon's avatar
      Backport into mysql-5.1.49sp1-release · a96c2a1f
      smenon authored
      > ------------------------------------------------------------
      > revno: 3452.1.12
      > revision-id: davi.arnaut@oracle.com-20100730121710-sc068t4d2f1c2gi9
      > parent: dao-gang.qu@sun.com-20100730035934-8in8err1b1rqu72y
      > committer: Davi Arnaut <davi.arnaut@oracle.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Fri 2010-07-30 09:17:10 -0300
      > message:
      >   Bug#54041: MySQL 5.0.92 fails when tests from Connector/C suite run
      >   
      >   Fix a regression (due to a typo) which caused spurious incorrect
      >   argument errors for long data stream parameters if all forms of
      >   logging were disabled (binary, general and slow logs).
      a96c2a1f
  4. 23 Sep, 2010 1 commit
    • Sergey Glukhov's avatar
      Bug#54494 crash with explain extended and prepared statements · 55390725
      Sergey Glukhov authored
      In case of outer join and emtpy WHERE conditon
      'always true' condition is created for WHERE clasue.
      Later in mysql_select() original SELECT_LEX WHERE
      condition is overwritten with created cond.
      However SELECT_LEX condition is also used as inital
      condition in mysql_select()->JOIN::prepare().
      On second execution of PS modified SELECT_LEX condition
      is taken and it leads to crash.
      The fix is to restore original SELECT_LEX condition
      (set to NULL if original cond is NULL) in
       reinit_stmt_before_use().
      HAVING clause is fixed too for safety reason
      (no test case as I did not manage to think out
       appropriate example).
      55390725
  5. 18 Aug, 2010 1 commit
    • 's avatar
      WL#5370 Keep forward-compatibility when changing · d3b7cd3f
      authored
              'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
      BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
      automatically after the this patch.
      BUG#55617 is fixed by this patch too.
                  
      This is the 5.5 part.
      It implements:
      - 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
        anything and binlog anything if the table already exists.
        It only generate a warning that table already exists.
      - A couple of test cases for the behavior changing.
      d3b7cd3f
  6. 30 Jul, 2010 2 commits
  7. 27 Jul, 2010 2 commits
    • Konstantin Osipov's avatar
      Implement WL#5502 Remove dead 5.0 class Sensitive_cursor. · 6d059673
      Konstantin Osipov authored
      Remove dead and unused code.
      Update to reflect the code review requests.
      6d059673
    • 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
  8. 21 Jul, 2010 1 commit
  9. 28 Jun, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#54041: MySQL 5.0.92 fails when tests from Connector/C suite run · 07767edc
      Davi Arnaut authored
      The problem was that a user could supply supply data in chunks
      via the COM_STMT_SEND_LONG_DATA command to prepared statement
      parameter other than of type TEXT or BLOB. This posed a problem
      since other parameter types aren't setup to handle long data,
      which would lead to a crash when attempting to use the supplied
      data.
      
      Given that long data can be supplied at any stage of a prepared
      statement, coupled with the fact that the type of a parameter
      marker might change between consecutive executions, the solution
      is to validate at execution time each parameter marker for which
      a data stream was provided. If the parameter type is not TEXT or
      BLOB (that is, if the type is not able to handle a data stream),
      a error is returned.
      07767edc
  10. 12 Jun, 2010 1 commit
  11. 10 Jun, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#42733: Type-punning warnings when compiling MySQL -- · 53b88296
      Davi Arnaut authored
                  strict aliasing violations.
      
      One somewhat major source of strict-aliasing violations and
      related warnings is the SQL_LIST structure. For example,
      consider its member function `link_in_list` which takes
      a pointer to pointer of type T (any type) as a pointer to
      pointer to unsigned char. Dereferencing this pointer, which
      is done to reset the next field, violates strict-aliasing
      rules and might cause problems for surrounding code that
      uses the next field of the object being added to the list.
      
      The solution is to use templates to parametrize the SQL_LIST
      structure in order to deference the pointers with compatible
      types. As a side bonus, it becomes possible to remove quite
      a few casts related to acessing data members of SQL_LIST.
      53b88296
  12. 25 May, 2010 1 commit
    • Dmitry Lenev's avatar
      Pre-requisite patch for bug #51263 "Deadlock between · a3c080be
      Dmitry Lenev authored
      transactional SELECT and ALTER TABLE ... REBUILD PARTITION".
      
      The goal of this patch is to decouple type of metadata
      lock acquired for table by open_tables() from type of
      table-level lock to be acquired on it.
      
      To achieve this we change approach to how we determine what
      type of metadata lock should be acquired on table to be open.
      Now instead of inferring it at open_tables() time from flags
      and type of table-level lock we rely on that type of metadata
      lock is properly set at parsing time and is not changed
      further.
      a3c080be
  13. 21 May, 2010 1 commit
    • Alexey Kopytov's avatar
      Bug #42064: low memory crash when importing hex strings, in · 779e2a96
      Alexey Kopytov authored
                  Item_hex_string::Item_hex_string
      
      The status of memory allocation in the Lex_input_stream (called
      from the Parser_state constructor) was not checked which led to
      a parser crash in case of the out-of-memory error.
      
      The solution is to introduce new init() member function in
      Parser_state and Lex_input_stream so that status of memory
      allocation can be returned to the caller.
      779e2a96
  14. 05 May, 2010 1 commit
  15. 04 May, 2010 1 commit
  16. 07 Apr, 2010 1 commit
    • Mats Kindahl's avatar
      WL#5030: Splitting mysql_priv.h · 0768deeb
      Mats Kindahl authored
      Adding my_global.h first in all files using
      NO_EMBEDDED_ACCESS_CHECKS.
      
      Correcting a merge problem resulting from a changed definition
      of check_some_access compared to the original patches.
      0768deeb
  17. 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
  18. 11 Mar, 2010 1 commit
    • Konstantin Osipov's avatar
      A fix for Bug#49972 "Crash in prepared statements": · 42b78128
      Konstantin Osipov authored
      The problem is introduced by WL#4435 "Support OUT-parameters in 
      prepared statements".
      When a statement that has out parameters was reprepared,
      the reprepare request error was ignored, and an
      attempt to send out parameters to the client was made.
      
      Since the out parameter list was not initialized in case
      of an error, this attempt led to a crash.
      
      Don't try to send out parameters to the client
      if an error occurred in statement execution.
      42b78128
  19. 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
  20. 16 Jan, 2010 1 commit
    • 's avatar
      BUG#47418 RBR fails, failure with mixup of base/temporary/view · 6f380d16
      authored
      'CREATE TABLE IF NOT EXISTS ... SELECT' statement were causing 'CREATE
      TEMPORARY TABLE ...' to be written to the binary log in row-based 
      mode (a.k.a. RBR), when there was a temporary table with the same name.
      Because the 'CREATE TABLE ... SELECT' statement was executed as 
      'INSERT ... SELECT' into the temporary table. Since in RBR mode no 
      other statements related to temporary tables are written into binary log,
      this sometimes broke replication.
      
      This patch changes behavior of 'CREATE TABLE [IF NOT EXISTS] ... SELECT ...'.
      it ignores existence of temporary table with the 
      same name as table being created and is interpreted
      as attempt to create/insert into base table. This makes behavior of
      'CREATE TABLE [IF NOT EXISTS] ... SELECT' consistent with
      how ordinary 'CREATE TABLE' and 'CREATE TABLE ... LIKE' behave.
      6f380d16
  21. 12 Jan, 2010 1 commit
    • Tor Didriksen's avatar
      Backport of · 6766c0d6
      Tor Didriksen authored
      Bug#45523 "Objects of class base_ilist should not be copyable".
                     
      Suppress the compiler-generated public copy constructor
      and assignment operator of class base_ilist; instead, implement
      move_elements_to() function which transfers ownership of elements
      from one list to another.
      6766c0d6
  22. 07 Jan, 2010 1 commit
  23. 29 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Apply and review: · 3b311f39
      Konstantin Osipov authored
      3655 Jon Olav Hauglid   2009-10-19
      Bug #30977 Concurrent statement using stored function and DROP FUNCTION 
                 breaks SBR
      Bug #48246 assert in close_thread_table
      
      Implement a fix for:
      Bug #41804 purge stored procedure cache causes mysterious hang for many
                 minutes
      Bug #49972 Crash in prepared statements
      
      The problem was that concurrent execution of DML statements that
      use stored functions and DDL statements that drop/modify the same
      function might result in incorrect binary log in statement (and
      mixed) mode and therefore break replication.
      
      This patch fixes the problem by introducing metadata locking for
      stored procedures and functions. This is similar to what is done
      in Bug#25144 for views. Procedures and functions now are
      locked using metadata locks until the transaction is either
      committed or rolled back. This prevents other statements from
      modifying the procedure/function while it is being executed. This
      provides commit ordering - guaranteeing serializability across
      multiple transactions and thus fixes the reported binlog problem.
      
      Note that we do not take locks for top-level CALLs. This means
      that procedures called directly are not protected from changes by
      simultaneous DDL operations so they are executed at the state they
      had at the time of the CALL. By not taking locks for top-level
      CALLs, we still allow transactions to be started inside
      procedures.
      
      This patch also changes stored procedure cache invalidation.
      Upon a change of cache version, we no longer invalidate the entire
      cache, but only those routines which we use, only when a statement
      is executed that uses them.
      
      This patch also changes the logic of prepared statement validation.
      A stored procedure used by a prepared statement is now validated
      only once a metadata lock has been acquired. A version mismatch
      causes a flush of the obsolete routine from the cache and
      statement reprepare.
      Incompatible changes:
      1) ER_LOCK_DEADLOCK is reported for a transaction trying to access
         a procedure/function that is locked by a DDL operation in
         another connection.
      
      2) Procedure/function DDL operations are now prohibited in LOCK
         TABLES mode as exclusive locks must be taken all at once and
         LOCK TABLES provides no way to specifiy procedures/functions to
         be locked.
      
      Test cases have been added to sp-lock.test and rpl_sp.test.
      
      Work on this bug has very much been a team effort and this patch
      includes and is based on contributions from Davi Arnaut, Dmitry
      Lenev, Magne Mæhre and Konstantin Osipov.
      3b311f39
  24. 22 Dec, 2009 2 commits
    • Konstantin Osipov's avatar
      A prerequisite patch for the fix for Bug#46224 · 39a1a50d
      Konstantin Osipov authored
      "HANDLER statements within a transaction might lead to deadlocks".
      Introduce a notion of a sentinel to MDL_context. A sentinel
      is a ticket that separates all tickets in the context into two
      groups: before and after it. Currently we can have (and need) only
      one designated sentinel -- it separates all locks taken by LOCK
      TABLE or HANDLER statement, which must survive COMMIT and ROLLBACK
      and all other locks, which must be released at COMMIT or ROLLBACK.
      The tricky part is maintaining the sentinel up to date when
      someone release its corresponding ticket. This can happen, e.g.
      if someone issues DROP TABLE under LOCK TABLES (generally,
      see all calls to release_all_locks_for_name()).
      MDL_context::release_ticket() is modified to take care of it.
      
      ******
      A fix and a test case for Bug#46224 "HANDLER statements within a
      transaction might lead to deadlocks".
      
      An attempt to mix HANDLER SQL statements, which are transaction-
      agnostic, an open multi-statement transaction,
      and DDL against the involved tables (in a concurrent connection) 
      could lead to a deadlock. The deadlock would occur when
      HANDLER OPEN or HANDLER READ would have to wait on a conflicting
      metadata lock. If the connection that issued HANDLER statement
      also had other metadata locks (say, acquired in scope of a 
      transaction), a classical deadlock situation of mutual wait
      could occur.
      
      Incompatible change: entering LOCK TABLES mode automatically
      closes all open HANDLERs in the current connection.
      
      Incompatible change: previously an attempt to wait on a lock
      in a connection that has an open HANDLER statement could wait
      indefinitely/deadlock. After this patch, an error ER_LOCK_DEADLOCK
      is produced.
      
      The idea of the fix is to merge thd->handler_mdl_context
      with the main mdl_context of the connection, used for transactional
      locks. This makes deadlock detection possible, since all waits
      with locks are "visible" and available to analysis in a single
      MDL context of the connection.
      
      Since HANDLER locks and transactional locks have a different life
      cycle -- HANDLERs are explicitly open and closed, and so
      are HANDLER locks, explicitly acquired and released, whereas
      transactional locks "accumulate" till the end of a transaction
      and are released only with COMMIT, ROLLBACK and ROLLBACK TO SAVEPOINT,
      a concept of "sentinel" was introduced to MDL_context.
      All locks, HANDLER and others, reside in the same linked list.
      However, a selected element of the list separates locks with
      different life cycle. HANDLER locks always reside at the
      end of the list, after the sentinel. Transactional locks are
      prepended to the beginning of the list, before the sentinel.
      Thus, ROLLBACK, COMMIT or ROLLBACK TO SAVEPOINT, only
      release those locks that reside before the sentinel. HANDLER locks
      must be released explicitly as part of HANDLER CLOSE statement,
      or an implicit close. 
      The same approach with sentinel
      is also employed for LOCK TABLES locks. Since HANDLER and LOCK TABLES
      statement has never worked together, the implementation is
      made simple and only maintains one sentinel, which is used either
      for HANDLER locks, or for LOCK TABLES locks.
      39a1a50d
    • 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
  25. 10 Dec, 2009 1 commit
    • Jon Olav Hauglid's avatar
      Backport of revno: 2617.71.1 · b20a409c
      Jon Olav Hauglid authored
      Bug#42546 Backup: RESTORE fails, thinking it finds an existing table
      
      The problem occured when a MDL locking conflict happened for a non-existent 
      table between a CREATE and a INSERT statement. The code for CREATE 
      interpreted this lock conflict to mean that the table existed, 
      which meant that the statement failed when it should not have.
      The problem could occur for CREATE TABLE, CREATE TABLE LIKE and
      ALTER TABLE RENAME.
      
      This patch fixes the problem for CREATE TABLE and CREATE TABLE LIKE.
      It is based on code backported from the mysql-6.1-fk tree written
      by Dmitry Lenev. CREATE now uses normal open_and_lock_tables() code 
      to acquire exclusive locks. This means that for the test case in the bug 
      description, CREATE will wait until INSERT completes so that it can 
      get the exclusive lock. This resolves the reported bug.
      
      The patch also prohibits CREATE TABLE and CREATE TABLE LIKE under 
      LOCK TABLES. Note that this is an incompatible change and must 
      be reflected in the documentation. Affected test cases have been
      updated.
      
      mdl_sync.test contains tests for CREATE TABLE and CREATE TABLE LIKE.
      
      Fixing the issue for ALTER TABLE RENAME is beyond the scope of this
      patch. ALTER TABLE cannot be prohibited from working under LOCK TABLES
      as this could seriously impact customers and a proper fix would require
      a significant rewrite.
      b20a409c
  26. 04 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5, · 0b39c189
      Konstantin Osipov authored
      2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
      - initial changeset that introduced the fix for 
      Bug#989 and follow up fixes for all test suite failures
      introduced in the initial changeset. 
      ------------------------------------------------------------
      revno: 2617.31.1
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 4284-6.0
      timestamp: Fri 2009-03-06 19:17:00 -0300
      message:
      Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
      WL#4284: Transactional DDL locking
      
      Currently the MySQL server does not keep metadata locks on
      schema objects for the duration of a transaction, thus failing
      to guarantee the integrity of the schema objects being used
      during the transaction and to protect then from concurrent
      DDL operations. This also poses a problem for replication as
      a DDL operation might be replicated even thought there are
      active transactions using the object being modified.
      
      The solution is to defer the release of metadata locks until
      a active transaction is either committed or rolled back. This
      prevents other statements from modifying the table for the
      entire duration of the transaction. This provides commitment
      ordering for guaranteeing serializability across multiple
      transactions.
      
      - Incompatible change:
      
      If MySQL's metadata locking system encounters a lock conflict,
      the usual schema is to use the try and back-off technique to
      avoid deadlocks -- this schema consists in releasing all locks
      and trying to acquire them all in one go.
      
      But in a transactional context this algorithm can't be utilized
      as its not possible to release locks acquired during the course
      of the transaction without breaking the transaction commitments.
      To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
      returned if a lock conflict is encountered during a transaction.
      
      Let's consider an example:
      
      A transaction has two statements that modify table t1, then table
      t2, and then commits. The first statement of the transaction will
      acquire a shared metadata lock on table t1, and it will be kept
      utill COMMIT to ensure serializability.
      
      At the moment when the second statement attempts to acquire a
      shared metadata lock on t2, a concurrent ALTER or DROP statement
      might have locked t2 exclusively. The prescription of the current
      locking protocol is that the acquirer of the shared lock backs off
      -- gives up all his current locks and retries. This implies that
      the entire multi-statement transaction has to be rolled back.
      
      - Incompatible change:
      
      FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
      LOCK won't cause locked tables to be implicitly unlocked anymore.
      0b39c189
  27. 30 Nov, 2009 2 commits
    • Konstantin Osipov's avatar
      Backport of: · f56cc2a3
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2630.4.16
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w
      timestamp: Thu 2008-05-29 09:45:02 +0400
      message:
        WL#3726 "DDL locking for all metadata objects".
      
        After review changes in progress.
      
        Tweaked some comments and did some renames to
        avoid ambiguites.
      f56cc2a3
    • 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
  28. 25 Nov, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 57ca07a5
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3184.3.13
      > revision-id: joro@sun.com-20091019135504-e6fmhf4xyy0wdymb
      > parent: joro@sun.com-20091026095557-euhe1z9oxtgkw35h
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B47788-5.1-bugteam
      > timestamp: Mon 2009-10-19 16:55:04 +0300
      > message:
      >   Bug #47788: Crash in TABLE_LIST::hide_view_error on 
      >     UPDATE + VIEW + SP + MERGE + ALTER
      >   
      >   When cleaning up the stored procedure's internal 
      >   structures the flag to ignore the errors for 
      >   INSERT/UPDATE IGNORE was not cleaned up.
      >   As a result error ignoring was on during name 
      >   resolution. And this is an abnormal situation : the
      >   SELECT_LEX flag can be on only during query execution.
      >   
      >   Fixed by correctly cleaning up the SELECT_LEX flag 
      >   when reusing the SELECT_LEX in a second execution.
      57ca07a5
  29. 23 Nov, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · 7edfae4e
      Konstantin Osipov authored
      -------------------------------------------------------------
      revno: 2877
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 35164-6.0
      timestamp: Wed 2008-10-15 19:53:18 -0300
      message:
      Bug#35164: Large number of invalid pthread_attr_setschedparam calls
      Bug#37536: Thread scheduling causes performance degradation at low thread count
      Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows
      
      The problem is that although having threads with different priorities
      yields marginal improvements [1] in some platforms [2], relying on some
      statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well
      (or to work at all) with different scheduling practices and disciplines
      is, at best, a shot in the dark as the meaning of priority values may
      change depending on the scheduling policy set for the process.
      
      Another problem is that increasing priorities can hurt other concurrent
      (running on the same hardware) applications (such as AMP) by causing
      starvation problems as MySQL threads will successively preempt lower
      priority processes. This can be evidenced by Bug#12702.
      
      The solution is to not change the threads priorities and rely on the
      system scheduler to perform its job. This also enables a system admin
      to increase or decrease the scheduling priority of the MySQL process,
      if intended.
      
      Furthermore, the internal wrappers and code for changing the priority
      of threads is being removed as they are now unused and ancient.
      
      1. Due to unintentional side effects. On Solaris this could artificially
      help benchmarks as calling the priority changing syscall millions of
      times is more beneficial than the actual setting of the priority.
      
      2. Where it actually works. It has never worked on Linux as the default
      scheduling policy SCHED_OTHER only accepts the static priority 0.
      7edfae4e
  30. 05 Nov, 2009 1 commit
  31. 23 Oct, 2009 1 commit
  32. 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
  33. 19 Oct, 2009 2 commits
    • Georgi Kodinov's avatar
      Bug #47788: Crash in TABLE_LIST::hide_view_error on · db944fda
      Georgi Kodinov authored
        UPDATE + VIEW + SP + MERGE + ALTER
      
      When cleaning up the stored procedure's internal 
      structures the flag to ignore the errors for 
      INSERT/UPDATE IGNORE was not cleaned up.
      As a result error ignoring was on during name 
      resolution. And this is an abnormal situation : the
      SELECT_LEX flag can be on only during query execution.
      
      Fixed by correctly cleaning up the SELECT_LEX flag 
      when reusing the SELECT_LEX in a second execution.
      db944fda
    • Kristofer Pettersson's avatar
      Bug#27145 EXTRA_ACL troubles · b5559f53
      Kristofer Pettersson authored
      The flag EXTRA_ACL is used in conjugation with our access checks, yet it is
      not clear what impact this flag has.
      This is a code clean up which replaces use of EXTRA_ACL with an explicit
      function parameter.
      The patch also fixes privilege checks for:
      - SHOW CREATE TABLE: The new privilege requirement is any privilege on
        the table-level.
      - CHECKSUM TABLE: Requires SELECT on the table level.
      - SHOW CREATE VIEW: Requires SHOW_VIEW and SELECT on the table level
        (just as the manual claims)
      - SHOW INDEX: Requires any privilege on any column combination.
      b5559f53
  34. 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
  35. 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