An error occurred fetching the project authors.
  1. 11 Sep, 2008 1 commit
    • Tatiana A. Nurnberg's avatar
      Bug#31434 mysqldump dumps view as table · 743149bc
      Tatiana A. Nurnberg authored
      mysqldump creates stand-in tables before dumping the actual view.
      Those tables were of the default type; if the view had more columns
      than that (a pathological case, arguably), loading the dump would
      fail. We now make the temporary stand-ins MyISAM tables to prevent
      this.
      743149bc
  2. 14 Apr, 2008 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#35157: mysqldump should use FLUSH TABLES NO_WRITE_TO_BINLOG \ · 13fa535b
      cmiller@zippy.cornsilk.net authored
      	when --master-data is used
      
      When using the --master-data option with mysqldump, mysqldump uses 
      a FLUSH TABLES command.  However, this statement got replicated to 
      the slave(s), which caused the slave(s) to block unnecessarily while
      the FLUSH tables command completed.
      
      Now, if the master-data option is set to one of the two "on" modes,
      then use the "LOCAL" qualifier to ensure that it's not replicated.
      13fa535b
  3. 12 Mar, 2008 1 commit
  4. 07 Mar, 2008 1 commit
  5. 18 Feb, 2008 1 commit
    • guilhem@gbichot4.local's avatar
      Fix for server bug experienced in Maria (wrong "Truncated incorrect <var_name> · 9e2b31b0
      guilhem@gbichot4.local authored
      value" error even though the value was correct): a C function in my_getopt.c
      was taking bool* in parameter and was called from C++ sql_plugin.cc,
      but on some Mac OS X sizeof(bool) is 1 in C and 4 in C++, giving funny
      mismatches. Fixed, all other occurences of bool in C are removed, future
      ones are blocked by a "C-bool-catcher" in my_global.h (use my_bool).
      9e2b31b0
  6. 17 Dec, 2007 1 commit
  7. 20 Nov, 2007 1 commit
  8. 02 Nov, 2007 1 commit
  9. 08 Oct, 2007 1 commit
  10. 04 Oct, 2007 2 commits
  11. 03 Oct, 2007 1 commit
  12. 02 Oct, 2007 1 commit
  13. 01 Oct, 2007 2 commits
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #31077. · 5fc81ee8
      gshchepa/uchum@gleb.loc authored
      mysqldump adds the "-- Dump completed on YYYY-MM-DD hh:mm:ss" string
      to the end of output if the --comments switch is on.
      The only way to suppress this line is to use --skip-comments/--compact
      switch.
      
      New switch has been added to the mysqldump client command line:
      --dump-date.
      
      For the compatibility with previous releases, by default the --dump-date
      is on.
      The --dump-date switch forces mysqldump to add date to the
      "-- Dump completed on ..." string at the end of output.
      The --skip-dump-date switch supresses the output of date string
      and uses short form of that commentary: "-- Dump completed".
      --skip-comments or --compact switches disable the whole commentary
      as usual.
      5fc81ee8
    • monty@mysql.com/narttu.mysql.fi's avatar
      Removed extra spaces · 315acca1
      monty@mysql.com/narttu.mysql.fi authored
      Added extra debug
      315acca1
  14. 13 Sep, 2007 1 commit
    • tnurnberg@mysql.com/sin.intern.azundris.com's avatar
      Bug #15327: configure: --with-tcp-port option being partially ignored · 3c6ca8d6
      make sure that if builder configured with a non-standard (!= 3306)
      default TCP port that value actually gets used throughout. if they
      didn't configure a value, assume "use a sensible default", which
      will be read from /etc/services or, failing that, from the factory
      default. That makes the order of preference
      - command-line option
      - my.cnf, where applicable
      - $MYSQL_TCP_PORT environment variable
      - /etc/services (unless configured --with-tcp-port)
      - default port (--with-tcp-port=... or factory default)
      3c6ca8d6
  15. 05 Sep, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29938. · adfbea36
      gshchepa/uchum@gleb.loc authored
      mysqldump --skip-events --all-databases dumped data of the mysqld.event table,
      and during the restoration from this dump events were created in spite
      of the --skip-events option.
      
      The mysqldump client has been modified to ignore mysql.event table data
      in case of --skip-events options.
      adfbea36
  16. 31 Aug, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30126. · 3e49bbd8
      gshchepa/uchum@gleb.loc authored
      When dumping database from a 4.x server, the mysqldump client
      inserted a delimiter sign inside special commentaries of the form:
        /*!... CREATE DATABASE IF NOT EXISTS ... ;*/
      During restoration that dump file was splitten by delimiter signs on
      the client side, and the rest of some commentary strings was prepended
      to following statements.
      
      The 4x_server_emul test case option has been added for use with the
      DBUG_EXECUTE_IF debugging macro. This option affects debug server
      builds only to emulate particular behavior of a 4.x server for
      the mysqldump client testing. Non-debugging builds are not affected.
      3e49bbd8
  17. 15 Aug, 2007 1 commit
  18. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2
  19. 06 Aug, 2007 4 commits
  20. 03 Aug, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Fix for BUG#30123: mysqldump is unable to work with old servers. · e76351df
      anozdrin/alik@ibm. authored
      New server (as of 5.1.21) provides new features:
        - SHOW CREATE TRIGGER;
        - character set information for SHOW TRIGGERS and SHOW CREATE
          EVENT | FUNCTION | PROCEDURE statements.
      Mysqldump uses these features to generate proper dump.
      
      The bug happened when new mysqldump was used to dump older servers.
      The problem was that 5.1.21 new features are not available, so
      mysqldump exited with error code or just crashed.
      
      The fix is to detect if mysqldump has ben run against older server
      and don't use new 5.1.21 functionality in this case. Certainly,
      the dump generated for the older server suffers from the character
      set problems fixed by BUG#16291 and the like.
      e76351df
  21. 02 Aug, 2007 2 commits
  22. 01 Aug, 2007 1 commit
  23. 27 Jul, 2007 2 commits
    • anozdrin/alik@ibm.'s avatar
      Fix for BUG#30027: mysqldump does not dump views properly. · e73f004f
      anozdrin/alik@ibm. authored
      mysqldump generates view defitions in two stages:
      
        - dump CREATE TABLE statements for the temporary tables.  For each view a
          temporary table, that has the same structure as the view is created.
      
        - dump DROP TABLE statements for the temporary tables and CREATE VIEW
          statements for the view.
      
      This approach is required because views can have dependencies on each other
      (a view can use other views). So, they should be created in the particular
      order. mysqldump however is not smart enough, so in order to resolve
      dependencies it creates temporary tables first of all.
      
      The problem was that mysqldump might have generated incorrect dump for the
      temporary table when a view has non-ASCII column name. That happened when
      default-character-set is not utf8.
      
      The fix is to:
      
        1. Switch character_set_client for the mysqldump's connection to binary
           before issuing SHOW FIELDS statement in order to avoid conversion.
          
        2. Dump switch character_set_client statements to UTF8 and back for
           CREATE TABLE statement that is issued to create temporary table.
      e73f004f
    • 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
  24. 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
  25. 20 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29788. · c3e925ee
      gshchepa/uchum@gleb.loc authored
      After dumping triggers mysqldump copied 
      the value of the OLD_SQL_MODE variable to the SQL_MODE
      variable. If the --compact option of the mysqldump was
      not set the OLD_SQL_MODE variable had the value
      of the uninitialized SQL_MODE variable. So
      usually the NO_AUTO_VALUE_ON_ZERO option of the
      SQL_MODE variable was discarded.
      
      This fix is for non-"--compact" mode of the mysqldump,
      because mysqldump --compact never set SQL_MODE to the
      value of NO_AUTO_VALUE_ON_ZERO.
      
      The dump_triggers_for_table function has been modified
      to restore previous value of the SQL_MODE variable after
      dumping triggers using the SAVE_SQL_MODE temporary
      variable.
      c3e925ee
  26. 18 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28524. · 3f91aeda
      gshchepa/uchum@gleb.loc authored
      For each view the mysqldump utility creates a temporary table
      with the same name and the same columns as the view 
      in order to satisfy views that depend on this view.
      After the creation of all tables, mysqldump drops all
      temporary tables and creates actual views.
      However, --skip-add-drop-table and --compact flags disable
      DROP TABLE statements for those temporary tables. Thus, it was
      impossible to create the views because of existence of the
      temporary tables with the same names.
      3f91aeda
  27. 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
  28. 29 Jun, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Folow up on the CS patch: · bceff6f1
      anozdrin/alik@ibm. authored
      1. Fix ddl_i18n_koi8r, ddl_i18n_utf8: explicitly specify character-sets
      directory for mysqldump;
      2. Fix crash in mysqldump if collation is not found;
      3. Use proper way to compare character set names.
      bceff6f1
  29. 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
    • msvensson@pilot.(none)'s avatar
      Bug#29361 mysqldump creates stray file when too long path name is passed · a1a1dbc7
      msvensson@pilot.(none) authored
       - Move the check of too long path to 'get_one_option'
      a1a1dbc7
  30. 30 May, 2007 2 commits
  31. 27 May, 2007 1 commit