An error occurred fetching the project authors.
- 11 Sep, 2008 1 commit
-
-
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.
-
- 14 Apr, 2008 1 commit
-
-
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.
-
- 12 Mar, 2008 1 commit
-
-
cmiller@zippy.cornsilk.net authored
databases from 4.0 server mysqldump treated a failure to set the results charset as a severe error. Now, don't try to set the charset for the SHOW CREATE TABLE statement, if remote server's version is earlier than 4.1, which means it doesn't support changing charsets.
-
- 07 Mar, 2008 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
--master-data No error code was returned by mysqldump if it detects that binary logging is not enabled on the server. Fixed by returning error code.
-
- 18 Feb, 2008 1 commit
-
-
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).
-
- 17 Dec, 2007 1 commit
-
-
show version of mysqldump, release of server et al., and version of current server in mysqldumps.
-
- 20 Nov, 2007 1 commit
-
-
guilhem@gbichot4.local authored
this has already been closed by a note in the manual, now we complete this by a note in "mysqldump --help"
-
- 02 Nov, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
db name should be quoted. this code does communication with the server. it's always ok to quote names in this case.
-
- 08 Oct, 2007 1 commit
-
-
iggy@alf.(none) authored
- Fixed error message.
-
- 04 Oct, 2007 2 commits
-
-
gluh@mysql.com/eagle.(none) authored
-
tnurnberg@sin.intern.azundris.com authored
The combination of --single-transaction and --master-data requires START TRANSACTION WITH CONSISTENT SNAPSHOT which is available from mysqld 4.1 on. When trying this against an older server, print diagnostic, then, if --force is not given, abort. No test-case given since it would require a mysqld < 4.1.
-
- 03 Oct, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Post-merge fix.
-
- 02 Oct, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Bug #31077: post-commit fix.
-
- 01 Oct, 2007 2 commits
-
-
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.
-
monty@mysql.com/narttu.mysql.fi authored
Added extra debug
-
- 13 Sep, 2007 1 commit
-
-
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)
-
- 05 Sep, 2007 1 commit
-
-
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.
-
- 31 Aug, 2007 1 commit
-
-
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.
-
- 15 Aug, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 13 Aug, 2007 1 commit
-
-
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()
-
- 06 Aug, 2007 4 commits
-
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
-
- 03 Aug, 2007 1 commit
-
-
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.
-
- 02 Aug, 2007 2 commits
-
-
gluh@mysql.com/eagle.(none) authored
-
monty@mysql.com/nosik.monty.fi authored
Fixed bug in query cache that made it impossible to run mysqld with --debug Fixed memory leaks in mysqldump and mysqltest Memory leaks associated with wrong usage of mysqltest is not fixed. To find these, run mysql-test-run --debug mysqltest
-
- 01 Aug, 2007 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
Fixed compiler warnings, errors and link errors Fixed new bug on Solaris with gethrtime() Added --debug-check option to all mysql clients to print errors and memory leaks Added --debug-info to all clients. This now works as --debug-check but also prints memory and cpu usage
-
- 27 Jul, 2007 2 commits
-
-
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.
-
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.
-
- 25 Jul, 2007 1 commit
-
-
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.
-
- 20 Jul, 2007 1 commit
-
-
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.
-
- 18 Jul, 2007 1 commit
-
-
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.
-
- 12 Jul, 2007 1 commit
-
-
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.
-
- 29 Jun, 2007 1 commit
-
-
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.
-
- 28 Jun, 2007 2 commits
-
-
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;
-
msvensson@pilot.(none) authored
- Move the check of too long path to 'get_one_option'
-
- 30 May, 2007 2 commits
-
-
tsmith@quadxeon.mysql.com authored
Fix harmless typo (caught thanks to warning)
-
tsmith@quadxeon.mysql.com authored
Fix harmless typo (caught thanks to warning)
-
- 27 May, 2007 1 commit
-
-
dkatz@damien-katzs-computer.local authored
fixed by using flush logs, dumping, then doing PURGE MASTER LOGS TO 'binfile', instead of deleting the log files at the beginning. NOTE: previously the delete-master-logs would reset the log names back to filename.00001. Now the trailing number doesn't get reset. This may need to be documented.
-