An error occurred fetching the project authors.
  1. 27 May, 2009 1 commit
    • Tatiana A. Nurnberg's avatar
      Bug#34861: mysqldump with --tab gives weird output for triggers. · 7eeff66c
      Tatiana A. Nurnberg authored
      mysqldump --tab still dumped triggers to stdout rather than to
      individual tables.
      
      We now append triggers to the .sql file for the corresponding
      table.
      
      --events and --routines correspond to a database rather than a
      table and will still go to stdout with --tab unless redirected
      with --result-file (-r).
      7eeff66c
  2. 21 Apr, 2009 1 commit
    • Sergey Vojtovich's avatar
      BUG#36966 - mysqldump.test fails in pushbuild · 90449829
      Sergey Vojtovich authored
      mysqldump.test is designed to run with concurrent inserts
      disabled. It is disabling concurrent inserts at the very
      beginning of the test case, and re-enables them at the
      bottom of the test. But for some reason (likely incorrect
      merge) we enable concurrent inserts in the middle of the test.
      
      The problem is fixed by enabling concurrent inserts only
      at the bottom of the test case.
      90449829
  3. 09 Mar, 2009 1 commit
    • Chad MILLER's avatar
      Bug#42635: mysqldump includes views that were excluded using the \ · 0d9589a4
      Chad MILLER authored
      	--ignore-table option
      
      mysqldump would correctly omit temporary tables for views, but would
      incorrectly still emit all CREATE VIEW statements.
      
      Backport a fix from 5.1, where we capture the names we want to emit
      views for in one pass (the placeholder tables) and in the pass where
      we actually emit the views, we don't emit a view if it wasn't in that
      list.
      0d9589a4
  4. 25 Feb, 2009 1 commit
  5. 02 Feb, 2009 2 commits
    • Matthias Leich's avatar
      1. Slice of fix for Bug#42003 tests missing the disconnect of connections <> default · 7da691c9
      Matthias Leich authored
         - If missing: add "disconnect <session>"
         - If physical disconnect of non "default" sessions is not finished
           at test end: add routine which waits till this happened
      + additional improvements like
        - remove superfluous files created by the test
        - replace error numbers by error names
        - remove trailing spaces, replace tabs by spaces
        - unify writing of bugs within comments
        - correct comments
        - minor changes of formatting
      Modifications according to the code review are included.
      Fixed tests:
      grant2
      grant3
      lock_tables_lost_commit
      mysqldump
      openssl_1
      outfile
      7da691c9
    • Tatiana A. Nurnberg's avatar
      Bug#33550: mysqldump 4.0 compatibility broken · 5622d426
      Tatiana A. Nurnberg authored
      mysqldump included character_set_client magic
      that is unknown before 4.1 even when asked for
      an appropriate compatibility mode.
      
      In compatibility (3.23, 4.0) mode, we do not
      output charset statements (not even in a
      "comment conditional"), nor do we do magic on
      the server, even if the server is sufficient
      new (4.1+). Table-names will be output converted
      to the charset requested by mysqldump; if such
      a conversion is not possible (Ivrit -> Latin),
      mysqldump will fail.
      5622d426
  6. 15 Sep, 2008 1 commit
    • Patrick Crews's avatar
      Bug#37938 Test "mysqldump" lacks various INSERT statements / values · ef1d6cca
      Patrick Crews authored
      Moved fix for this bug to 5.0 as other mysqldump bugs seem tied to concurrent_insert being on
      Setting concurrent_insert off during this test as INSERTs weren't being 
      completely processed before the calls to mysqldump, resulting in failing tests.
      
      Altered .test file to turn concurrent_insert off during the test and to restore it
      to whatever the value was at the start of the test when complete.
      
      Re-recorded .result file to account for changes to variables in the test.
      ef1d6cca
  7. 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
  8. 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
  9. 02 Mar, 2008 1 commit
  10. 22 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#30217: Views: changes in metadata behaviour · 340906f4
      anozdrin/alik@quad. authored
      between 5.0 and 5.1.
        
      The problem was that in the patch for Bug#11986 it was decided
      to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
      This approach however turned out to be quite difficult to implement
      properly. The main problem is to preserve the same IS-output after
      dump/restore.
        
      So, the fix is to rollback to the previous functionality, but also
      to fix it to support multi-character-set-queries properly. The idea
      is to generate INFORMATION_SCHEMA-query from the item-tree after
      parsing view declaration. The IS-query should:
        - be completely in UTF8;
        - not contain character set introducers.
        
      For more information, see WL4052.
      340906f4
  11. 13 Feb, 2008 1 commit
  12. 12 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#32538: View definition picks up character set, · d36d243d
      anozdrin/alik@quad. authored
      but not collation.
      
      The problem here was that text literals in a view were always
      dumped with character set introducer. That lead to loosing
      collation information.
      
      The fix is to dump character set introducer only if it was
      in the original query. That is now possible because there 
      is no problem any more of loss of character set of string
      literals in views -- after WL#4052 the view is dumped 
      in the original character set.
      d36d243d
  13. 02 Nov, 2007 1 commit
  14. 04 Oct, 2007 1 commit
  15. 03 Oct, 2007 1 commit
  16. 02 Oct, 2007 1 commit
  17. 01 Oct, 2007 1 commit
    • 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
  18. 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
  19. 27 Jul, 2007 3 commits
    • anozdrin/alik@ibm.'s avatar
      Fix merge. · 47345bd0
      anozdrin/alik@ibm. authored
      47345bd0
    • anozdrin/alik@ibm.'s avatar
    • 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
  20. 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
  21. 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
  22. 19 Jul, 2007 1 commit
  23. 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
  24. 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
  25. 27 May, 2007 1 commit
  26. 25 May, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28522: · 2ee30b0b
      gshchepa/uchum@gleb.loc authored
      sometimes `mysqldump --hex-blob' overruned output buffer by '\0' byte.
      
      The dump_table() function has been fixed to reserve 1 byte more for the
      last '\0' byte of dumped string.
      2ee30b0b
  27. 16 May, 2007 1 commit
  28. 14 May, 2007 1 commit
  29. 01 May, 2007 1 commit
  30. 30 Apr, 2007 2 commits
    • tnurnberg@mysql.com/blasphemy.mysql.com's avatar
      Bug#27293: mysqldump crashes when dumping procedure defined by different user · 205dfa44
      mysqldump didn't properly handle getting no data on
      SHOW CREATE PROCEDURE.  If S/C/P fails (due to dumping
      user's insufficient privileges on mysql.proc, say),
      mysqldump will print a comment to that effect to the
      output and return an error-code.  If the -f (force) option
      is used, the dump will continue, otherwise, it will abort
      right there and then.
      
      Also fixes Bug#22761, "mysqldump reports no errors when using
      --routines without mysql.proc privileges"
      ---
      Merge mysql.com:/home/tnurnberg/27293/50-27293
      into  mysql.com:/home/tnurnberg/27293/51-27293
      ---
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.1-maint
      into  mysql.com:/home/tnurnberg/27293/51-27293
      205dfa44
    • tnurnberg@mysql.com/blasphemy.mysql.com's avatar
      Bug#27293: mysqldump crashes when dumping procedure defined by different user · ce1074f6
      mysqldump didn't properly handle getting no data on
      SHOW CREATE PROCEDURE.  If S/C/P fails (due to dumping
      user's insufficient privileges on mysql.proc, say),
      mysqldump will print a comment to that effect to the
      output and return an error-code.  If the -f (force) option
      is used, the dump will continue, otherwise, it will abort
      right there and then.
      
      Also fixes Bug#22761, "mysqldump reports no errors when using
      --routines without mysql.proc privileges"
      ---
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
      into  mysql.com:/home/tnurnberg/27293/50-27293
      ce1074f6
  31. 29 Mar, 2007 2 commits
  32. 27 Mar, 2007 1 commit
  33. 26 Mar, 2007 2 commits