An error occurred fetching the project authors.
  1. 12 Dec, 2007 1 commit
    • msvensson@pilot.mysql.com's avatar
      WL#4189 · d918988b
      msvensson@pilot.mysql.com authored
       - dynamic configuration support
       - safe process
       - cleanups
       - create new suite for fedarated
      d918988b
  2. 01 Aug, 2007 1 commit
  3. 28 Jul, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      show_check.result: · 51f8aa96
      gkodinov/kgeorge@magare.gmz authored
        Addendum to thr fix for bug 30000:
        show procedure/function code defined only in debug builds
      show_check.test:
        Addendum to thr fix for bug 30000: 
        show procedure/function code defined only in debug builds
      51f8aa96
  4. 27 Jul, 2007 2 commits
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30000: SHOW commands once again ends up in the · 9e1dd00f
      gkodinov/kgeorge@magare.gmz authored
       slow query log
      Disable the SHOW commands to appear in the show query
      log.
      Update the commands type array.
      9e1dd00f
    • malff/marcsql@weblab.(none)'s avatar
      WL#3984 (Revise locking of mysql.general_log and mysql.slow_log) · c7bbd891
      malff/marcsql@weblab.(none) authored
      Bug#25422 (Hang with log tables)
      Bug 17876 (Truncating mysql.slow_log in a SP after using cursor locks the
                thread)
      Bug 23044 (Warnings on flush of a log table)
      Bug 29129 (Resetting general_log while the GLOBAL READ LOCK is set causes
                 a deadlock)
      
      Prior to this fix, the server would hang when performing concurrent
      ALTER TABLE or TRUNCATE TABLE statements against the LOG TABLES,
      which are mysql.general_log and mysql.slow_log.
      
      The root cause traces to the following code:
      in sql_base.cc, open_table()
        if (table->in_use != thd)
        {
          /* wait_for_condition will unlock LOCK_open for us */
          wait_for_condition(thd, &LOCK_open, &COND_refresh);
        }
      The problem with this code is that the current implementation of the
      LOGGER creates 'fake' THD objects, like
      - Log_to_csv_event_handler::general_log_thd
      - Log_to_csv_event_handler::slow_log_thd
      which are not associated to a real thread running in the server,
      so that waiting for these non-existing threads to release table locks
      cause the dead lock.
      
      In general, the design of Log_to_csv_event_handler does not fit into the
      general architecture of the server, so that the concept of general_log_thd
      and slow_log_thd has to be abandoned:
      - this implementation does not work with table locking
      - it will not work with commands like SHOW PROCESSLIST
      - having the log tables always opened does not integrate well with DDL
      operations / FLUSH TABLES / SET GLOBAL READ_ONLY
      
      With this patch, the fundamental design of the LOGGER has been changed to:
      - always open and close a log table when writing a log
      - remove totally the usage of fake THD objects
      - clarify how locking of log tables is implemented in general.
      
      See WL#3984 for details related to the new locking design.
      
      Additional changes (misc bugs exposed and fixed):
      
      1)
      
      mysqldump which would ignore some tables in dump_all_tables_in_db(),
       but forget to ignore the same in dump_all_views_in_db().
      
      2)
      
      mysqldump would also issue an empty "LOCK TABLE" command when all the tables
      to lock are to be ignored (numrows == 0), instead of not issuing the query.
      
      3)
      
      Internal errors handlers could intercept errors but not warnings
      (see sql_error.cc).
      
      4)
      
      Implementing a nested call to open tables, for the performance schema tables,
      exposed an existing bug in remove_table_from_cache(), which would perform:
        in_use->some_tables_deleted=1;
      against another thread, without any consideration about thread locking.
      This call inside remove_table_from_cache() was not required anyway,
      since calling mysql_lock_abort() takes care of aborting -- cleanly -- threads
      that might hold a lock on a table.
      This line (in_use->some_tables_deleted=1) has been removed.
      c7bbd891
  5. 26 Jul, 2007 1 commit
  6. 25 Jul, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Patch inspired by BUG#10491: Server returns data as charset · 9f8593e8
      anozdrin/alik@ibm. authored
      binary SHOW CREATE TABLE or SELECT FROM I_S.
      
      The problem is that mysqldump generates incorrect dump for a table
      with non-ASCII column name if the mysqldump's character set is
      ASCII.
      
      The fix is to:
        1. Switch character_set_client for the mysqldump's connection
        to binary before issuing SHOW CREATE TABLE statement in order
        to avoid conversion.
        
        2. Dump switch character_set_client statements to UTF8 and back
        for CREATE TABLE statement.
      9f8593e8
  7. 12 Jul, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Fix for 5.1 for BUG#10491: Server returns data as charset binary · 3f2e94c4
      anozdrin/alik@ibm. authored
      SHOW CREATE TABLE or SELECT FROM I_S.
      
      This is the last patch for this bug, which depends on the big
      CS patch and was pending.
      
      The problem was that SHOW CREATE statements returned original
      queries in the binary character set. That could cause the query
      to be unreadable.
      
      The fix is to use original character_set_client when sending
      the original query to the client. In order to preserve the query
      in mysqldump, 'binary' character set results should be set when
      issuing SHOW CREATE statement. If either source or destination
      character set is 'binary' , no conversion is performed.
      The idea is that since the source character set is no longer
      'binary', we fix the destination character set to still produce
      valid dumps.
      3f2e94c4
  8. 05 Jul, 2007 1 commit
  9. 28 Jun, 2007 2 commits
    • anozdrin/alik@ibm.'s avatar
      Patch for the following bugs: · 9fae9ef6
      anozdrin/alik@ibm. authored
        - BUG#11986: Stored routines and triggers can fail if the code
          has a non-ascii symbol
        - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
        - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
        - BUG#21249: Character set of SP-var can be ignored
        - BUG#25212: Character set of string constant is ignored (stored routines)
        - BUG#25221: Character set of string constant is ignored (triggers)
      
      There were a few general problems that caused these bugs:
      1. Character set information of the original (definition) query for views,
         triggers, stored routines and events was lost.
      2. mysqldump output query in client character set, which can be
         inappropriate to encode definition-query.
      3. INFORMATION_SCHEMA used strings with mixed encodings to display object
         definition;
      
      1. No query-definition-character set.
      
      In order to compile query into execution code, some extra data (such as
      environment variables or the database character set) is used. The problem
      here was that this context was not preserved. So, on the next load it can
      differ from the original one, thus the result will be different.
      
      The context contains the following data:
        - client character set;
        - connection collation (character set and collation);
        - collation of the owner database;
      
      The fix is to store this context and use it each time we parse (compile)
      and execute the object (stored routine, trigger, ...).
      
      2. Wrong mysqldump-output.
      
      The original query can contain several encodings (by means of character set
      introducers). The problem here was that we tried to convert original query
      to the mysqldump-client character set.
      
      Moreover, we stored queries in different character sets for different
      objects (views, for one, used UTF8, triggers used original character set).
      
      The solution is
        - to store definition queries in the original character set;
        - to change SHOW CREATE statement to output definition query in the
          binary character set (i.e. without any conversion);
        - introduce SHOW CREATE TRIGGER statement;
        - to dump special statements to switch the context to the original one
          before dumping and restore it afterwards.
      
      Note, in order to preserve the database collation at the creation time,
      additional ALTER DATABASE might be used (to temporary switch the database
      collation back to the original value). In this case, ALTER DATABASE
      privilege will be required. This is a backward-incompatible change.
      
      3. INFORMATION_SCHEMA showed non-UTF8 strings
      
      The fix is to generate UTF8-query during the parsing, store it in the object
      and show it in the INFORMATION_SCHEMA.
      
      Basically, the idea is to create a copy of the original query convert it to
      UTF8. Character set introducers are removed and all text literals are
      converted to UTF8.
      
      This UTF8 query is intended to provide user-readable output. It must not be
      used to recreate the object.  Specialized SHOW CREATE statements should be
      used for this.
      
      The reason for this limitation is the following: the original query can
      contain symbols from several character sets (by means of character set
      introducers).
      
      Example:
      
        - original query:
          CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
      
        - UTF8 query (for INFORMATION_SCHEMA):
          CREATE VIEW v1 AS SELECT 'Hello' AS c1;
      9fae9ef6
    • anozdrin/alik@ibm.'s avatar
      Fix for BUG#10491: Server returns data as charset binary · 6794da11
      anozdrin/alik@ibm. authored
      SHOW CREATE TABLE or SELECT FROM I_S.
      
      Actually, the bug discovers two problems:
        - the original query is not preserved properly. This is the problem
          of BUG#16291;
        - the resultset of SHOW CREATE TABLE statement is binary.
      
      This patch fixes the second problem for the 5.0.
      
      Both problems will be fixed in 5.1.
      6794da11
  10. 15 Jun, 2007 1 commit
    • bar@mysql.com/bar.myoffice.izhnet.ru's avatar
      Additional fix for bug N26402: · f28a5842
      bar@mysql.com/bar.myoffice.izhnet.ru authored
      An attempt to open file with name '????????.frm'
      can produce different errors:
      - ER_NO_SUCH_TABLE on Unix
      - ER_FILE_NOT_FOUND on Windows
      because QUESTION MARK has special meaning on Windows.
      Make sure that any of these two errors happens.
      f28a5842
  11. 14 Jun, 2007 1 commit
    • bar@mysql.com/bar.myoffice.izhnet.ru's avatar
      Bug#26402 Server crashes with old-style named table · 6d2ffe7b
      bar@mysql.com/bar.myoffice.izhnet.ru authored
        Problem: crash on attempt to open a table
        having "#mysql50#" prefix in db or table name.
        Fix: This prefix is reserved for "mysql_upgrade"
        to access 5.0 tables  whose file names are not encoded
        according to "5.1 tablename to filename encoded".
        Don't try open tables whose db name or table name
        has this prefix.
      6d2ffe7b
  12. 06 Jun, 2007 1 commit
    • jimw@rama.(none)'s avatar
      Bug #28842 Different 'duplicate key' error code between 5.0 and 5.1 · 3c93323d
      jimw@rama.(none) authored
        The patch for WL 1563 added a new duplicate key error message so that the
        key name could be provided instead of the key number. But the error code
        for the new message was used even though that did not need to change.
      
        This could cause unnecessary problems for applications that used the old
        ER_DUP_ENTRY error code to detect duplicate key errors.
      3c93323d
  13. 16 Apr, 2007 1 commit
  14. 23 Jan, 2007 2 commits
    • malff/marcsql@weblab.(none)'s avatar
      Bug#24392 (SHOW ENGINE MUTEX STATUS is a synonym for SHOW INNODB STATUS) · 2bd3c8fd
      malff/marcsql@weblab.(none) authored
      Before this fix, the command SHOW ENGINE <name> STATUS would:
      - print a warning if the engine name is unknown,
      - proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
      and list the status of all the storage engines registered.
      
      In particular, this behavior caused confusion about the command :
      SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
      of the innodb engine when that engine is registered.
      
      Also, before this fix, every time an unknown engine name was substituted by
      the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
      set), a malformed warning was raised.
      For example, the command ALTER TABLE T1 ENGINE = X would print :
      Warnings:
      Error 1286 Unknown table engine 'X'
      
      With this fix:
      SHOW ENGINE <name> STATUS|LOGS|MUTEX
      always fails with an error when the engine <name> is unknown.
      
      For other commands, warnings about unknown engines are raised as:
      Warnings:
      Warning 1286 Unknown table engine 'X'
      
      In other words, engine substitution never affect the SHOW ENGINE command,
      since this would lead to very confusing results.
      2bd3c8fd
    • bar@mysql.com's avatar
      Bug#25081 SHOW FULL TABLES on table with latin chars in name fails · f3156a18
      bar@mysql.com authored
      Problem: The Table_type column of "SHOW FULL TABLES" displayed
      "ERROR" instead of "BASE TABLE" for tables having non-ascii
      characters in their names.
      Reason: tablename to filename encoding was missing, so
      mysql_frm_type() tried to open a wrong file name.
      
      Fix: adding tablename to filename encoding
      f3156a18
  15. 22 Jan, 2007 1 commit
  16. 23 Oct, 2006 1 commit
  17. 12 Oct, 2006 2 commits
  18. 04 Oct, 2006 1 commit
  19. 01 Sep, 2006 1 commit
  20. 28 Jul, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Bug#16581: deadlock: server and client both read from connection in · d06001b1
      kroki/tomash@moonlight.intranet authored
                 'conc_sys' test
      
      Concurrent execution of SELECT involing at least two INFORMATION_SCHEMA
      tables, DROP DATABASE statement and DROP TABLE statement could have
      resulted in stalled connection for this SELECT statement.
      
      The problem was that for the first query of a join there was a race
      between select from I_S.TABLES and DROP DATABASE, and the error (no
      such database) was prepared to be send to the client, but the join
      processing was continued.  On second query to I_S.COLUMNS there was a
      race with DROP TABLE, but this error (no such table) was downgraded to
      warning, and thd->net.report_error was reset.  And so neither result
      nor error was sent to the client.
      
      The solution is to stop join processing once it is clear we are going
      to report a error, and also to downgrade to warnings file system errors
      like 'no such database' (unless we are in the 'SHOW' command), because
      I_S is designed not to use locks and the query to I_S should not abort
      if something is dropped in the middle.
      
      No test case is provided since this bug is a result of a race, and is
      timing dependant.  But we test that plain SHOW TABLES and SHOW COLUMNS
      give a error if there is no such database or a table respectively.
      d06001b1
  21. 28 Jun, 2006 1 commit
  22. 27 Jun, 2006 1 commit
  23. 01 Jun, 2006 1 commit
  24. 22 Feb, 2006 1 commit
  25. 24 Jan, 2006 1 commit
  26. 19 Jan, 2006 1 commit
  27. 31 Dec, 2005 1 commit
    • bar@mysql.com's avatar
      WL#1324 table name to file name encoding · 6ff21132
      bar@mysql.com authored
      - Encoding itself, implemented as a charset
        "filename". Originally planned to use '.'
        as an escape character, but now changed to '@'
        for two reasons: "ls" does not return
        file names starting with '.' considering them
        as a kind of hidden files; some platforms
        do not allow several dots in a file name.
      - replacing many calls of my_snprintf() and
        strnxmov() to the new build_table_filename().
      - Adding MY_APPEND_EXT mysys flag, to append
        an extention rather that replace it.
      - Replacing all numeric constants in fn_format
        flag arguments to their mysys definitions, e.g.
        MY_UNPACK_FILENAME,
      - Predictability in several function/methods:
        when a table name can appear with or withot .frm
        extension. Some functions/methods were changed
        so accept names strictly with .frm, other - strictly
        without .frm extensions. Several DBUG_ASSERTs were
        added to check whether an extension is passed.
      Many files:
        table name to file name encoding
      mysql_priv.h:
        Prototypes for new table name encoding tools.
      ctype-utf8.c:
        Implementing "filename" charset for
        table name to file name encoding.
      row0mysql.c:
        Fixing table name prefix.
      mf_format.c:
        Adding MY_APPEND_EXT processing.
      Many files:
        Fixing tests.
      my_sys.h:
        Adding new flag to append rather than replace an extension.
      m_ctype.h:
        Adding "filename" charset definition.
      6ff21132
  28. 07 Dec, 2005 1 commit
    • anozdrin@mysql.com's avatar
      Patch for WL#2894: Make stored routine variables work · 0ff8f60b
      anozdrin@mysql.com authored
      according to the standard.
      
      The idea is to use Field-classes to implement stored routines
      variables. Also, we should provide facade to Item-hierarchy
      by Item_field class (it is necessary, since SRVs take part
      in expressions).
      
      The patch fixes the following bugs:
        - BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data 
          type matching; 
       
        - BUG#8768: Functions: For any unsigned data type, -ve values can be passed 
          and returned; 
       
        - BUG#8769: Functions: For Int datatypes, out of range values can be passed 
          and returned; 
       
        - BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use 
          DECIMAL datatype; 
       
        - BUG#9572: Stored procedures: variable type declarations ignored; 
       
        - BUG#12903: upper function does not work inside a function; 
       
        - BUG#13705: parameters to stored procedures are not verified; 
       
        - BUG#13808: ENUM type stored procedure parameter accepts non-enumerated
          data; 
       
        - BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores 
          CHARACTER SET); 
       
        - BUG#14161: Stored procedure cannot retrieve bigint unsigned;
      
        - BUG#14188: BINARY variables have no 0x00 padding;
      
        - BUG#15148: Stored procedure variables accept non-scalar values;
      0ff8f60b
  29. 01 Dec, 2005 1 commit
  30. 28 Nov, 2005 1 commit
  31. 10 Nov, 2005 1 commit
  32. 07 Nov, 2005 1 commit
  33. 13 Oct, 2005 1 commit
  34. 17 Aug, 2005 1 commit
  35. 16 Aug, 2005 1 commit
  36. 28 Jul, 2005 1 commit