An error occurred fetching the project authors.
  1. 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
  2. 23 Nov, 2009 3 commits
    • 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
    • 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
    • Konstantin Osipov's avatar
      Backport of: · 7e532b13
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2642
      committer: davi@mysql.com/endora.local
      timestamp: Fri 2008-05-16 01:29:09 -0300
      message:
      Fix for a valgrind warning due to a jump on a uninitialized
      variable. The problem was that the sql profile preparation
      function wasn't being called for all possible code paths
      of query execution. The solution is to move the preparation
      to the dispatch_command function and to explicitly call the
      profile preparation function on bootstrap.
      7e532b13
  3. 10 Nov, 2009 5 commits
    • Davi Arnaut's avatar
      Backport of Bug#45767 to mysql-next-mr · ed800b5d
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 3405
      revision-id: davi.arnaut@sun.com-20090626124624-m4wolyo5193j4cu7
      parent: luis.soares@sun.com-20090626113019-1j4mn1jos480u9f3
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: mysql-pe
      timestamp: Fri 2009-06-26 09:46:24 -0300
      message:
        Bug#45767: deprecate/remove Field::pack_key, Field::unpack_key, Field::pack_cmp
        
        Remove unused and dead code.
        
        Parts of the patch contributed by Zardosht Kasheff
      ed800b5d
    • Davi Arnaut's avatar
      Backport of Bug#15192 to mysql-next-mr · a7bbc779
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2597.4.17
      revision-id: sp1r-davi@mysql.com/endora.local-20080328174753-24337
      parent: sp1r-anozdrin/alik@quad.opbmk-20080328140038-16479
      committer: davi@mysql.com/endora.local
      timestamp: Fri 2008-03-28 14:47:53 -0300
      message:
        Bug#15192 "fatal errors" are caught by handlers in stored procedures
      
        The problem is that fatal errors (e.g.: out of memory) were being
        caught by stored procedure exception handlers which could cause
        the execution to not be stopped due to a continue handler.
      
        The solution is to not call any exception handler if the error is
        fatal and send the fatal error to the client.
      a7bbc779
    • Davi Arnaut's avatar
      Backport of Bug#27525 to mysql-next-mr · 40c127eb
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2572.2.1
      revision-id: sp1r-davi@mysql.com/endora.local-20080227225948-16317
      parent: sp1r-anozdrin/alik@quad.-20080226165712-10409
      committer: davi@mysql.com/endora.local
      timestamp: Wed 2008-02-27 19:59:48 -0300
      message:
        Bug#27525 table not found when using multi-table-deletes with aliases over several databas
        Bug#30234 Unexpected behavior using DELETE with AS and USING
      
        The multi-delete statement has a documented limitation that
        cross-database multiple-table deletes using aliases are not
        supported because it fails to find the tables by alias if it
        belongs to a different database. The problem is that when
        building the list of tables to delete from, if a database
        name is not specified (maybe an alias) it defaults to the
        name of the current selected database, making impossible to
        to properly resolve tables by alias later. Another problem
        is a inconsistency of the multiple table delete syntax that
        permits ambiguities in a delete statement (aliases that refer
        to multiple different tables or vice-versa).
      
        The first step for a solution and proper implementation of
        the cross-databse multiple table delete is to get rid of any
        ambiguities in a multiple table statement. Currently, the parser
        is accepting multiple table delete statements that have no obvious
        meaning, such as:
      
        DELETE a1 FROM db1.t1 AS a1, db2.t2 AS a1;
        DELETE a1 AS a1 FROM db1.t1 AS a1, db2.t2 AS a1;
      
        The solution is to resolve the left part of a delete statement
        using the right part, if the a table on right has an alias,
        it must be referenced in the left using the given alias. Also,
        each table on the left side must match unambiguously only one
        table in the right side.
      40c127eb
    • Davi Arnaut's avatar
      Backport of Bug#36649 to mysql-next-mr · 20189faa
      Davi Arnaut authored
      ------------------------------------------------------------
      revno: 2630.39.3
      revision-id: davi.arnaut@sun.com-20081210215359-i876m4zgc2d6rzs3
      parent: kostja@sun.com-20081208222938-9es7wl61moli71ht
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 36649-6.0
      timestamp: Wed 2008-12-10 19:53:59 -0200
      message:
        Bug#36649: Condition area is not properly cleaned up after stored routine invocation
      
        The problem is that the diagnostics area of a trigger is not
        isolated from the area of the statement that caused the trigger
        invocation. In MySQL terms, it means that warnings generated
        during the execution of the trigger are not removed from the
        "warning area" at the end of the execution.
      
        Before this fix, the rules for MySQL message list life cycle (see
        manual entry for SHOW WARNINGS) did not apply to statements
        inside stored programs:
      
          - The manual says that the list of messages is cleared by a
            statement that uses a table (any table). However, such
            statement, if run inside a stored program did not clear the
            message list.
          - The manual says that the list is cleared by a statement that
            generates a new error or a warning, but this was not the case
            with stored program statements either and is changed to be the
            case as well.
      
        In other words, after this fix, a statement has the same effect
        on the message list regardless of whether it's executed inside a
        stored program/sub-statement or not.
      
        This introduces an incompatible change:
      
          - before this fix, a, e.g. statement inside a trigger could
            never clear the global warning list
          - after this fix, a trigger that generates a warning or uses a
            table, clears the global warning list
          - however, when we leave a trigger or a function, the caller's
            warning information is restored (see more on this below).
      
        This change is not backward compatible as it is intended to make
        MySQL behavior similar to the SQL standard behavior:
      
        A stored function or trigger will get its own "warning area" (or,
        in standard terminology, diagnostics area).  At the beginning of
        the stored function or trigger, all messages from the caller area
        will be copied to the area of the trigger.  During execution, the
        message list will be cleared according to the MySQL rules
        described on the manual (SHOW WARNINGS entry).  At the end of the
        function/trigger, the "warning area" will be destroyed along with
        all warnings it contains, except that if the last statement of
        the function/trigger generated messages, these are copied into
        the "warning area" of the caller.
      
        Consequently, statements that use a table or generate a warning
        *will* clear warnings inside the trigger, but that will have no
        effect to the warning list of the calling (outer) statement.
      20189faa
    • Kristofer Pettersson's avatar
      Bug#27145 EXTRA_ACL troubles · 08aecd54
      Kristofer Pettersson authored
      Correction of backport patch:
      * Fixed signature of check_access_table() for embedded build
      * Fixed typo for last argument in a check_access() call from UINT_MAX to 0.
      08aecd54
  4. 05 Nov, 2009 1 commit
  5. 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
  6. 29 Oct, 2009 1 commit
    • Marc Alff's avatar
      Bug#33637 SHOW PROCEDURE CODE/SHOW FUNCTION CODE sp_name gives a syntax error. · 6a67daaa
      Marc Alff authored
      Backport for 5.5
      
      In non debug builds, the statements:
      - SHOW PROCEDURE CODE
      - SHOW FUNCTION CODE
      used to fail with a "syntax error", which is misleading.
      
      These statements have been changed to return the following error for non
      debug builds:
      ERROR HY000: The 'SHOW PROCEDURE|FUNCTION CODE' feature is disabled; you
      need MySQL built with '--with-debug' to have it working
      
      For debug builds (./configure --with-debug), nothing is changed.
      6a67daaa
  7. 28 Oct, 2009 1 commit
  8. 23 Oct, 2009 2 commits
  9. 22 Oct, 2009 1 commit
    • Alexander Nozdrin's avatar
      Backporting patches for Bug#38347 (ALTER ROUTINE privilege · 09195da3
      Alexander Nozdrin authored
      allows SHOW CREATE TABLE) from 6.0. Original revisions:
      ------------------------------------------------------------
      revno: 2617.31.8
      committer: Alexander Nozdrin <alik@sun.com>
      branch nick: 6.0-rt-bug38347
      timestamp: Thu 2009-03-26 09:08:24 +0300
      message:
        Patch for Bug#38347: ALTER ROUTINE privilege allows SHOW CREATE TABLE.
        
        If a user has any of the following privileges for a table (or the database
        if the table), he should be able to issue SHOW CREATE TABLE for the table:
          - CREATE
          - DROP
          - ALTER
          - DELETE
          - INDEX
          - INSERT
          - SELECT
          - UPDATE
          - TRIGGER
          - REFERENCES
          - GRANT OPTION
          - CREATE VIEW
          - SHOW VIEW
        
        Any other privilege (even SUPER) should not allow SHOW CREATE TABLE.
      ------------------------------------------------------------
      revno: 2617.31.11
      committer: Alexander Nozdrin <alik@sun.com>
      branch nick: 6.0-rt
      timestamp: Fri 2009-03-27 21:36:34 +0300
      message:
        Additional patch for Bug#38347 (ALTER ROUTINE privilege
        allows SHOW CREATE TABLE).
        
        The problem was that information_schema.test,
        information_schema_parameters.test and information_schema_routines.test
        failed with the first patch. That happened due to limitation in check_access():
        it allows only SELECT_ACL privilege for INFORMATION_SCHEMA tables.
        
        The patch is to request only SELECT_ACL privilege for INFORMATION_SCHEMA tables.
      ------------------------------------------------------------
      09195da3
  10. 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
  11. 19 Oct, 2009 1 commit
    • 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
  12. 16 Oct, 2009 2 commits
    • Martin Hansson's avatar
      Bug#46019: ERROR 1356 When selecting from within another · c6a11dff
      Martin Hansson authored
                  view that has Group By
            
      When SELECT'ing from a view that mentions another,
      materialized, view, access was being denied. The issue was
      resolved by lifting a special case which avoided such access
      checking in check_single_table_access. In the past, this was
      necessary since if such a check were performed, the error
      message would be downgraded to a warning in the case of SHOW
      CREATE VIEW. The downgrading of errors was meant to handle
      only that scenario, but could not distinguish the two as it
      read only the error messages.
            
      The special case was needed in the fix of bug no 36086.
      Before that, views were confused with derived tables.
            
      After bug no 35996 was fixed, the manipulation of errors
      during SHOW CREATE VIEW execution is not dependent on the
      actual error messages in the queue, it rather looks at the
      actual cause of the error and takes appropriate
      action. Hence the aforementioned special case is now
      superfluous and the bug is fixed.
      c6a11dff
    • 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
  13. 15 Oct, 2009 1 commit
  14. 13 Oct, 2009 1 commit
    • Konstantin Osipov's avatar
      Introduce thd->query_cache_tls (thread · ea6a22bf
      Konstantin Osipov authored
      local storage for query cache). 
      We need more than one pointer in a thread to
      represent the query cache and net->query_cache_query can not be used
      any more (due to ABI compatibility issues and to different life
      time of NET and THD).
      This is a backport of the following patch from 6.0:
      ----------------------------------------------------------
      revno: 2476.1157.2
      committer: kostja@bodhi.(none)
      timestamp: Sat 2007-06-16 13:29:24 +0400
      ea6a22bf
  15. 09 Oct, 2009 3 commits
    • Alexander Nozdrin's avatar
      A backporting patch for WL#4300 (Define privileges for tablespaces). · 132ef2e2
      Alexander Nozdrin authored
      Original revision in 6.0:
      ------------------------------------------------------------
      revno: 2630.13.11
      committer: Alexander Nozdrin <alik@mysql.com>
      branch nick: 6.0-rt-wl4300
      timestamp: Thu 2008-07-24 11:44:21 +0400
      message:
        A patch for WL#4300: Define privileges for tablespaces.
      ------------------------------------------------------------
      
      per-file messages:
        mysql-test/r/grant.result
          Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
        mysql-test/r/ps.result
          Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
        mysql-test/r/system_mysql_db.result
          Update result file: new columm 'Create_tablespace_priv' has been added to mysql.user.
        mysql-test/suite/falcon/r/falcon_tablespace_priv.result
          Test case for WL#4300.
        mysql-test/suite/falcon/t/falcon_tablespace_priv.test
          Test case for WL#4300.
        mysql-test/suite/ndb/r/ndb_dd_ddl.result
          Test case for WL#4300.
        mysql-test/suite/ndb/t/ndb_dd_ddl.test
          Test case for WL#4300.
        scripts/mysql_system_tables.sql
          New columm 'Create_tablespace_priv' has been added to mysql.user.
        scripts/mysql_system_tables_data.sql
          'CREATE TABLESPACE' is granted by default to the root user.
        scripts/mysql_system_tables_fix.sql
          Grant 'CREATE TABLESPACE' privilege during system table upgrade
          if a user had SUPER privilege.
        sql/sql_acl.cc
          Added CREATE TABLESPACE privilege.
        sql/sql_acl.h
          Added CREATE TABLESPACE privilege.
        sql/sql_parse.cc
          Check global 'CREATE TABLESPACE' privilege for the following SQL statements:
            - CREATE | ALTER | DROP TABLESPACE
            - CREATE | ALTER | DROP LOGFILE GROUP
        sql/sql_show.cc
          Added CREATE TABLESPACE privilege.
        sql/sql_yacc.yy
          Added CREATE TABLESPACE privilege.
      132ef2e2
    • Dmitry Lenev's avatar
      This patch is prerequisite for the 2nd milestone of WL#148 "Foreign keys" · d4669dc4
      Dmitry Lenev authored
      storing and restoring information about foreign keys in the .FRM files and
      properly displaying it in SHOW CREATE TABLE output and I_S tables.
      
      The idea of this patch is to change type of Key_part_spec::field_name and
      Key::name to LEX_STRING in order to avoid extra strlen() calls during
      semantic analysis and statement execution, particularly, in code to be
      implemented on the 2nd milestone of WL#148.
      
      Note that since we are not using LEX_STRING everywhere yet (e.g. in
      Create_field and KEY) and we want to limit scope of our changes we
      have to do strlen() in places where we create Key and Key_part_spec
      instances from objects using plain (char*) for strings. These calls
      will go away during the process of further (char*) -> LEX_STRING
      refactoring.
      
      We have introduced these changes in 6.0 and backported them to 5.5
      tree to make people aware of these changes as early as possible and
      to simplify merges with mysql-fk and mysql-6.1-fk trees.
      
      No test case is needed since this patch does not introduce any
      user visible changes.
      d4669dc4
    • Jon Olav Hauglid's avatar
      Bug #44651 "have_community_features" variable should be renamed · 0eccb932
      Jon Olav Hauglid authored
                 "have_profiling"
      
      1) Renamed have_community_features server system variable to
      have_profiling.
      2) Removed eable-community-features configure option and
      ENABLE_COMMUNITY_FEATURES macro.
      3) Removed COMMUNITY_SERVER macro and replaced its usage by 
      ENABLED_PROFILING.
      
      Only --enable-profiling is now needed to enable profiling.
      It was the only existing "community feature", so there was
      no need for both configure options.
      
      Using --enable-community-features will give a warning message
      since it no longer exists.
      0eccb932
  16. 07 Oct, 2009 1 commit
  17. 30 Sep, 2009 3 commits
  18. 29 Sep, 2009 1 commit
    • Luis Soares's avatar
      BUG#23300: Slow query log on slave does not log slow replicated statements · 7cf99622
      Luis Soares authored
            
      NOTE: this is the backport to next-mr.
            
      When using replication, the slave will not log any slow query logs queries 
      replicated from the master, even if the option "--log-slow-slave-statements" 
      is set and these take more than "log_query_time" to execute.
                    
      In order to log slow queries in replicated thread one needs to set the
      --log-slow-slave-statements, so that the SQL thread is initialized with the 
      correct switch. Although setting this flag correctly configures the slave 
      thread option to log slow queries, there is an issue with the condition that 
      is used to check whether to log the slow query or not. When replaying binlog 
      events the statement contains the SET TIMESTAMP clause which will force the 
      slow logging condition check to fail. Consequently, the slow query logging will
      not take place.
                    
      This patch addresses this issue by removing the second condition from the
      log_slow_statements as it prevents slow queries to be binlogged and seems 
      to be deprecated.
      7cf99622
  19. 28 Sep, 2009 1 commit
    • Luis Soares's avatar
      BUG#28777, WL#4293: SHOW BINLOG EVENTS does not work on relay log · d28ef002
      Luis Soares authored
      files
      
      NOTE: this is the backport to next-mr.
                  
      SHOW BINLOG EVENTS does not work with relay log files. If issuing
      "SHOW BINLOG EVENTS IN 'relay-log.000001'" in a non-empty relay
      log file (relay-log.000001), mysql reports empty set.
                  
      This patch addresses this issue by extending the SHOW command
      with RELAYLOG. Events in relay log files can now be inspected by
      issuing SHOW RELAYLOG EVENTS [IN 'log_name'] [FROM pos] [LIMIT
      [offset,] row_count].
      d28ef002
  20. 26 Sep, 2009 1 commit
  21. 10 Sep, 2009 2 commits
  22. 28 Aug, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 2217de25
      Staale Smedseng authored
      with gcc 4.3.2
            
      This patch fixes a number of GCC warnings about variables used
      before initialized. A new macro UNINIT_VAR() is introduced for
      use in the variable declaration, and LINT_INIT() usage will be
      gradually deprecated. (A workaround is used for g++, pending a
      patch for a g++ bug.)
            
      GCC warnings for unused results (attribute warn_unused_result)
      for a number of system calls (present at least in later
      Ubuntus, where the usual void cast trick doesn't work) are
      also fixed.
      2217de25
  23. 24 Jul, 2009 2 commits
  24. 16 Jul, 2009 1 commit
  25. 01 Jul, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #45790 Potential DoS vector: Writing of user input to log · 490f4432
      Staale Smedseng authored
      without proper formatting
            
      The problem is that a suitably crafted database identifier
      supplied to COM_CREATE_DB or COM_DROP_DB can cause a SIGSEGV,
      and thereby a denial of service. The database name is printed
      to the log without using a format string, so potential
      attackers can control the behavior of my_b_vprintf() by
      supplying their own format string. A CREATE or DROP privilege
      would be required.
            
      This patch supplies a format string to the printing of the
      database name. A test case is added to mysql_client_test.
      490f4432
  26. 29 Jun, 2009 1 commit