summaryrefslogtreecommitdiff
path: root/client/mysqldump.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.0 into 10.1Marko Mäkelä2017-03-091-2/+3
|\ | | | | | | | | | | | | | | | | Also, implement MDEV-11027 a little differently from 5.5 and 10.0: recv_apply_hashed_log_recs(): Change the return type back to void (DB_SUCCESS was always returned). Report progress also via systemd using sd_notifyf().
| * Merge branch '5.5' into 10.0Vicențiu Ciorbaru2017-03-031-2/+3
| |\
| | * MDEV-11505 wrong databasename in mysqldump commentSergei Golubchik2017-02-271-2/+3
| | | | | | | | | | | | | | | fix_for_comment() uses a static buffer. cannot have two fix_for_comment() calls as arguments to one printf().
* | | Merge branch '10.0-galera' into 10.1Sergei Golubchik2016-11-021-17/+43
|\ \ \ | |/ /
| * | Merge branch '5.5' into 10.0Sergei Golubchik2016-10-251-17/+43
| |\ \ | | |/
| | * mysqldump: comments and identifiers with new linesSergei Golubchik2016-10-141-17/+43
| | | | | | | | | | | | don't let identifiers with new lines to break a comment
* | | Merge branch '10.0' into 10.1Sergei Golubchik2016-06-281-23/+22
|\ \ \ | |/ /
| * | Merge branch '5.5' into bb-10.0Sergei Golubchik2016-06-211-23/+22
| |\ \ | | |/
| | * Merge branch 'mysql/5.5' into 5.5Sergei Golubchik2016-06-141-22/+23
| | |\
| | | * Bug#21977380 - POSSIBLE BUFFER OVERFLOW ISSUESShishir Jaiswal2016-05-161-22/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DESCRIPTION =========== Buffer overflow is reported in a lot of code sections spanning across server, client programs, Regex libraries etc. If not handled appropriately, they can cause abnormal behaviour. ANALYSIS ======== The reported casea are the ones which are likely to result in SEGFAULT, MEMORY LEAK etc. FIX === - sprintf() has been replaced by my_snprintf() to avoid buffer overflow. - my_free() is done after checking if the pointer isn't NULL already and setting it to NULL thereafter at few places. - Buffer is ensured to be large enough to hold the data. - 'unsigned int' (aka 'uint') is replaced with 'size_t' to avoid wraparound. - Memory is freed (if not done so) after its alloced and used. - Inserted assert() for size check in InnoDb memcached code (from 5.6 onwards) - Other minor changes (cherry picked from commit 3487e20959c940cbd24429afa795ebfc8a01e94f)
* | | | Merge branch '10.0' into 10.1Sergei Golubchik2016-05-041-1/+1
|\ \ \ \ | |/ / /
| * | | Merge branch '5.5' into 10.0Sergei Golubchik2016-04-261-1/+1
| |\ \ \ | | |/ /
| | * | Merge branch 'mysql/5.5' into 5.5Sergei Golubchik2016-04-201-1/+1
| | |\ \ | | | |/
| | | * WL#9072: Backport WL#8785 to 5.5Ramil Kalimullin2016-02-191-4/+5
| | | |
* | | | Merge branch '10.0' into 10.1Sergei Golubchik2015-12-211-75/+131
|\ \ \ \ | |/ / /
| * | | Merge branch '5.5' into 10.0Sergei Golubchik2015-12-131-12/+9
| |\ \ \ | | |/ /
| | * | Merge branch 'bb-5.5-serg' into 5.5Sergei Golubchik2015-12-091-1/+1
| | |\ \
| | | * \ Merge branch 'mysql/5.5' into 5.5Sergei Golubchik2015-12-091-1/+1
| | | |\ \ | | | | |/
| | | | * Bug #21235226 : THE --ENABLE-CLEARTEXT-PLUGIN IS NOTArun Kuruvila2015-10-141-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IMPLEMENTED IN ALL CLIENT PROGRAMS Description: Option "enable-cleartext-plugin" is not available for the following client utilities:- mysqldump mysqlimport mysqlshow mysqlcheck Analysis: The unavailability of this option limits the features like PAM authentication from using the above mentioned utilities. Fix: Option "enable-cleartext-plugin" is implemented in the above mentioned client utilities.
| | | | * BUG#18779944: MYSQLDUMP BUFFER OVERFLOWMarcin Babij2014-07-021-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mysqldump overflows stack buffer when copying table name from commandline arguments resulting in stack corruption and ability to execute arbitrary code. Fix: Check length of all positional arguments passed to mysqldump is smaller than NAME_LEN. Note: Mysqldump heavily depends on that database objects (databases, tablespaces, tables, etc) are limited to small size (now it is 64).
| | | | * BUG#18779944: MYSQLDUMP BUFFER OVERFLOWMarcin Babij2014-06-301-28/+11
| | | | | | | | | | | | | | | Reverted change due to mtr test failure.
| | | | * BUG#18779944: MYSQLDUMP BUFFER OVERFLOWMarcin Babij2014-06-271-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mysqldump overflows stack buffer when copying table name from commandline arguments resulting in stack corruption and ability to execute arbitrary code. Fix: Check length of all positional arguments passed to mysqldump is smaller than NAME_LEN. Note: Mysqldump heavily depends on that database objects (databases, tablespaces, tables, etc) are limited to small size (now it is 64).
| | | | * BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYINGNisha Gopalakrishnan2013-07-181-2/+2
| | | | |\ | | | | | | | | | | | | | | | | | | | | | | | | TO DUMP DATA FROM MYSQL-5.6 Merge from mysql-5.1 to mysql-5.5.
| | | | | * BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYINGNisha Gopalakrishnan2013-07-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TO DUMP DATA FROM MYSQL-5.6 Analysis -------- Dumping mysql-5.6 data using mysql-5.1/mysql-5.5 'myqldump' utility fails with a syntax error. Server system variable 'sql_quote_show_create' which quotes the identifiers is set in the mysqldump utility. The mysldump utility of mysql-5.1/mysql-5.5 uses deprecated syntax 'SET OPTION' to set the 'sql_quote_show_create' option. The support for the syntax is removed in mysql-5.6. Hence syntax error is reported while taking the dump. Fix: --- Changed the 'mysqldump' code to use the syntax 'SET SQL_QUOTE_SHOW_CREATE' to set the 'sql_quote_show_create' option. That syntax is supported on mysql-5.1, mysql-5.5 and mysql-5.6. NOTE: I have not added an mtr test case since it is difficult to simulate the condition. Also the syntax may not be further simplified in the future.
| | | | * | Bug#14236170 MYSQLDUMP 5.5.25 CLIENT FAILS TO DUMPVenkatesh Duggirala2013-05-171-26/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MYSQL DB FROM REMOTE 5.0.96 SERVER Problem: mysqldump tool assumes the existence of general_log and slow_log tables in the server. If mysqldump tool executes on a old server where there are no log tables like these, mysqldump tool fails. Analysis: general_log and slow_log tables are added in the ignore-table list as part of bug-26121 fix causes bug-45740 (MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY CAUSES RESTORE PROBLEM). As part of the bug-45740 fix, mysqldump tool adds create table queries for these two tables. But the fix assumes that on all the servers, general_log and slow_log will be there. If the new mysqldump tool is executed against a old server where there are no general_log and slow_log, the mysqldump tool fails with an error that 'there is no general_log table'. Fix: When mysqldump tool is trying to retrieve general_log and slow_log table structures, first the tool should check their existence of these tables in the server instead of trying to dump it blindly.
| | | | * | BUG#16615117 MYSQLDUMP PRODUCES A CHANGE MASTER STATEMENTVenkatesh Duggirala2013-04-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WITH A PORT NUMBER ENCLOSED IN QUOTES Problem: mysqldump --dump-slave --include-master-host-port prints the CHANGE MASTER command in the generated logical backup. The PORT number that is generated with this command is a string and should be an integer. Fix: Remove the Enclosed quotes for port number.
| | | | * | Fix for Bug 16395495 - OLD FSF ADDRESS IN GPL HEADERMurthy Narkedimilli2013-03-191-1/+1
| | | | | |
| | | | * | Updated/added copyright headersMurthy Narkedimilli2013-02-261-1/+1
| | | | |\ \ | | | | | |/
| | | | | * Updated/added copyright headers.Murthy Narkedimilli2013-02-251-1/+1
| | | | | |
| | | | | * BUG#14117025: UNABLE TO RESTORE DUMPAnirudh Mangipudi2013-01-161-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: When a view, with a specific character set and collation, is created on another view with a different character set and collation the dump restoration results in an illegal mix of collations error. SOLUTION: To avoid this confusion of collations, the create table datatype being used is hardcoded as "tinyint NOT NULL". This will not matter as the table created will be dropped at runtime and specifically tinyint is used to avoid hitting the row size conflicts.
| | | | * | Bug#14463669 FAILURE TO CORRECTLY PARSE ROUTINES INVamsikrishna Bhagi2012-11-191-15/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MYSQLDUMP OUTPUT Problem: mysqldump when used with option --routines, dumps all the routines of the specified database into output. The statements in this output are written in such a way that they are version safe using C style version commenting (of the format /*!<version num> <sql statement>*/). If a semicolon is present right before closing of the comment in dump output, it results in a syntax error while importing. Solution: Version comments for dumped routines are specifically to protect the ones older than 5.0. When the import is done on 5.0 or later versions, entire create statement gets executed as all the check conditions at the beginning of the comments are cleared. Since the trade off is between the performance of newer versions which are more in use and protection of very old versions which are no longer supported, it is proposed that these comments be removed altogether to maintain stability of the versions supported.
| | | | * | BUG#11762933: MYSQLDUMP WILL SILENTLY SKIP THE `EVENT`Anirudh Mangipudi2012-11-091-1/+2
| | | | |\ \ | | | | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TABLE DATA IF DUMPS MYSQL DATABA Problem: If mysqldump is run without --events (or with --skip-events) it will not dump the mysql.event table's data. This behaviour is inconsistent with that of --routines option, which does not affect the dumping of mysql.proc table. According to the Manual, --events (--skip-events) defines, if the Event Scheduler events for the dumped databases should be included in the mysqldump output and this has nothing to do with the mysql.event table itself. Solution: A warning has been added when mysqldump is used without --events (or with --skip-events) and a separate patch with the behavioral change will be prepared for 5.6/trunk.
| | | | | * BUG#11762933: MYSQLDUMP WILL SILENTLY SKIP THE `EVENT`Anirudh Mangipudi2012-11-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TABLE DATA IF DUMPS MYSQL DATABA Problem: If mysqldump is run without --events (or with --skip-events) it will not dump the mysql.event table's data. This behaviour is inconsistent with that of --routines option, which does not affect the dumping of mysql.proc table. According to the Manual, --events (--skip-events) defines, if the Event Scheduler events for the dumped databases should be included in the mysqldump output and this has nothing to do with the mysql.event table itself. Solution: A warning has been added when mysqldump is used without --events (or with --skip-events) and a separate patch with the behavioral change will be prepared for 5.6/trunk.
| | | | * | Merge of patch for Bug#13928675 from mysql-5.1.Nirbhay Choubey2012-08-071-3/+1
| | | | |\ \ | | | | | |/
| | | | | * Bug#13928675 MYSQL CLIENT COPYRIGHT NOTICE MUSTNirbhay Choubey2012-08-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SHOW 2012 INSTEAD OF 2011 * Added a new macro to hold the current year : COPYRIGHT_NOTICE_CURRENT_YEAR * Modified ORACLE_WELCOME_COPYRIGHT_NOTICE macro to take the initial year as parameter and pick current year from the above mentioned macro.
| | | | | * Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY Venkata Sidagam2012-05-071-8/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CAUSES RESTORE PROBLEM Problem Statement: ------------------ mysqldump is not having the dump stmts for general_log and slow_log tables. That is because of the fix for Bug#26121. Hence, after dropping the mysql database, and applying the dump by enabling the logging, "'general_log' table not found" errors are logged into the server log file. Analysis: --------- As part of the fix for Bug#26121, we skipped the dumping of tables for general_log and slow_log, because the data dump of those tables are taking LOCKS, which is not allowed for log tables. Fix: ---- We came up with an approach that instead of taking both meta data and data dump information for those tables, take only the meta data dump which doesn't need LOCKS. As part of fixing the issue we came up with below algorithm. Design before fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. Design with the fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Explicitly call the 'show create table' for general_log and slow_log 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. While taking the meta data dump for general_log and slow_log the "CREATE TABLE" is replaced with "CREATE TABLE IF NOT EXISTS". This is because we skipped "DROP TABLE" for those tables, "DROP TABLE" fails for these tables if logging is enabled. Customer is applying the dump by enabling logging so, if the dump has "DROP TABLE" it will fail. Hence, removed the "DROP TABLE" stmts for those tables. After the fix we could observe "Table 'mysql.general_log' doesn't exist" errors initially that is because in the customer scenario they are dropping the mysql database by enabling the logging, Hence, those errors are expected. Once we apply the dump which is taken before the "drop database mysql", the errors will not be there.
| | | | * | Bug #11753490: 44939: sql dumps containing broad views fail when Georgi Kodinov2012-07-041-7/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | executing The problem is that mysql lacks information about the objects a view depends on so it can't dump views and tables in the proper order. Thus it needs to create "stand-in" myisam tables for each view while dumping the tables that it later drops and replaces with the actual view view definition. But since views can have much more columns than an actual table creating these stand-in tables may be problematic. There's no way to portably find out how many columns an mysiam table can have. It's a complicated formula depending on internal server constants. Thus we can't have a reliable error check without repeating the logic and the formula inside mysqldump. 1. Changed the type of the columns of the stand-in tables mysqldump makes to satisfy view dependencies from the original type to smallint to save on row space. 2. Added a warning on the mysqldump's standard error for a possible problems replaying the dump file if the columns of a view exceed 1000. 3. Added a test case.
| | | | * | Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERYVenkata Sidagam2012-05-071-8/+50
| | | | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | CAUSES RESTORE PROBLEM Merging the fix from mysql-5.1 to mysql-5.5
| | | | | * | Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY Venkata Sidagam2012-05-041-8/+50
| | | | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CAUSES RESTORE PROBLEM Problem Statement: ------------------ mysqldump is not having the dump stmts for general_log and slow_log tables. That is because of the fix for Bug#26121. Hence, after dropping the mysql database, and applying the dump by enabling the logging, "'general_log' table not found" errors are logged into the server log file. Analysis: --------- As part of the fix for Bug#26121, we skipped the dumping of tables for general_log and slow_log, because the data dump of those tables are taking LOCKS, which is not allowed for log tables. Fix: ---- We came up with an approach that instead of taking both meta data and data dump information for those tables, take only the meta data dump which doesn't need LOCKS. As part of fixing the issue we came up with below algorithm. Design before fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. Design with the fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Explicitly call the 'show create table' for general_log and slow_log 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. While taking the meta data dump for general_log and slow_log the "CREATE TABLE" is replaced with "CREATE TABLE IF NOT EXISTS". This is because we skipped "DROP TABLE" for those tables, "DROP TABLE" fails for these tables if logging is enabled. Customer is applying the dump by enabling logging so, if the dump has "DROP TABLE" it will fail. Hence, removed the "DROP TABLE" stmts for those tables. After the fix we could observe "Table 'mysql.general_log' doesn't exist" errors initially that is because in the customer scenario they are dropping the mysql database by enabling the logging, Hence, those errors are expected. Once we apply the dump which is taken before the "drop database mysql", the errors will not be there.
| | | | * | Further upmerge the yaSSL upgrade (to 2.2.0) from MySQL 5.1 to 5.5.Joerg Bruehe2012-03-021-2/+2
| | | | |\ \ | | | | | |/ | | | | | | | | | | | | Also, take a syntax fix (C++ style comment in C file) in client/mysqldump.c.
| | | | | * AIX builds fail for comments using //Karen Langford2012-02-281-2/+2
| | | | | |
| | | | * | Updated/added copyright headersMySQL Build Team2012-02-161-1/+1
| | | | |\ \ | | | | | |/
| | | | | * Updated/added copyright headersKent Boortz2012-02-151-1/+1
| | | | | |\
| | | | | * | Bug #11760384 52792: MYSQLDUMP IN XML MODE DOES NOTNirbhay Choubey2012-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DUMP ROUTINES Minor post-fix to avoid build failure when built with Werror.
| | | | * | | fix compile warning: may be used uninitializedTor Didriksen2012-01-121-1/+1
| | | | | | |
| | | | * | | Merge of fix for bug#11760384 from mysql-5.1.Nirbhay Choubey2012-01-101-131/+335
| | | | |\ \ \ | | | | | |/ /
| | | | | * | BUG#11760384 - 52792: mysqldump in XML mode does not dumpNirbhay Choubey2012-01-101-128/+333
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | routines. mysqldump in xml mode did not dump routines, events or triggers. This patch fixes this issue by fixing the if conditions that disallowed the dump of above mentioned objects in xml mode, and added the required code to enable dump in xml format.
| | | | * | | Bug#12809202 61854: MYSQLDUMP --SINGLE-TRANSACTIONNirbhay Choubey2011-12-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --FLUSH-LOG BREAKS CONSISTENCY Post-fix for some failing tests.
| | | | * | | Bug#12809202 61854: MYSQLDUMP --SINGLE-TRANSACTIONNirbhay Choubey2011-12-231-10/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --FLUSH-LOG BREAKS CONSISTENCY The transaction started by mysqldump gets committed implicitly when flush-log is specified along with single-transaction option, and hence can break consistency. This is because, COM_REFRESH is executed in order to flush logs and starting from 5.5 this command performs an implicit commit. Fixed by making sure that COM_REFRESH is executed before the transaction has started and not after it. Note : This patch triggers following behavioral changes in mysqldump : 1) After this patch we no longer flush logs before dumping each database if --single-transaction option is given like it was done before (in the absence of --lock-all-tables and --master-data options). 2) Also, after this patch, we start acquiring FTWRL before flushing logs in cases when only --single-transaction and --flush-logs are given. It becomes safe to use mysqldump with these two options and without --master-data parameter for backups.
| | | | * | | Manual merge from mysql-5.1.Alexander Nozdrin2011-07-221-1/+3
| | | | |\ \ \ | | | | | |/ /
View Lorry Controller Status