From 5b225518ff2193834804ddb403ac6c0f9a265884 Mon Sep 17 00:00:00 2001 From: Dmitry Lenev Date: Thu, 16 Jun 2011 19:18:16 +0400 Subject: Fix for bug #12641342 - "61401: UPDATE PERFORMANCE DEGRADES GRADUALLY IF A TRIGGER EXISTS". This bug manifested itself in two ways: - Firstly execution of any data-changing statement which required prelocking (i.e. involved stored function or trigger) as part of transaction slowed down a bit all subsequent statements in this transaction. So performance in transaction which periodically involved such statements gradually degraded over time. - Secondly execution of any data-changing statement which required prelocking as part of transaction prevented concurrent FLUSH TABLES WITH READ LOCK from proceeding until the end of transaction instead of end of particular statement. The problem was caused by incorrect handling of metadata lock used in FTWRL implementation for statements requiring prelocked mode. Each statement which changes data acquires global IX lock with STATEMENT duration. This lock is supposed to block concurrent FTWRL from proceeding until the statement ends. When entering prelocked mode, durations of all metadata locks acquired so far were changed to EXPLICIT, to prevent substatements from releasing these locks. When prelocked mode was left, durations of metadata locks were changed to TRANSACTIONAL (with a few exceptions) so they can be properly released at the end of transaction. Unfortunately, this meant that the global IX lock blocking FTWRL with STATEMENT duration was moved to TRANSACTIONAL duration after execution of statement requiring prelocking. Since each subsequent statement that required prelocking and tried to acquire global IX lock with STATEMENT duration got a new instance of MDL_ticket, which was later moved to TRANSACTIONAL duration, this led to unwarranted growth of number of tickets with TRANSACITONAL duration in this connection's MDL_context. As result searching for other tickets in it became slow and acquisition of other metadata locks by this transaction started to hog CPU. Moreover, this also meant that after execution of statement requiring prelocking concurrent FTWRL was blocked until the end of transaction instead of end of statement. This patch solves this problem by not moving locks to EXPLICIT duration when thread enters prelocked mode (unless it is a real LOCK TABLES mode). This step turned out to be not really necessary as substatements don't try to release metadata locks. Consequently, the global IX lock blocking FTWRL keeps its STATEMENT duration and is properly released at the end of statement and the above issue goes away. mysql-test/r/flush.result: Added test for bug #12641342 - "61401: UPDATE PERFORMANCE DEGRADES GRADUALLY IF A TRIGGER EXISTS". mysql-test/t/flush.test: Added test for bug #12641342 - "61401: UPDATE PERFORMANCE DEGRADES GRADUALLY IF A TRIGGER EXISTS". sql/mdl.h: Added comment describing various types of metadata lock duration. sql/sql_class.cc: Since we no longer change duration of metadata locks to EXPLICIT when entering prelocked mode (unless it is a real LOCK TABLES) there is no need to restore proper duration of the locks when leaving prelocked mode. sql/sql_class.h: Do not change duration of metadata locks to EXPLICIT when entering prelocking mode (unless it is a real LOCK TABLES). This allows to avoid problems with restoring correct duration when leaving this mode. It is possible to do this as substatements won't release metadata locks in any case. sql/sql_parse.cc: Added assert checking that we won't release metadata locks when in substatement. --- sql/sql_parse.cc | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'sql/sql_parse.cc') diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index 44a9243d8f5..36fdf376fa6 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -2027,6 +2027,11 @@ mysql_execute_command(THD *thd) */ if (stmt_causes_implicit_commit(thd, CF_IMPLICT_COMMIT_BEGIN)) { + /* + Note that this should never happen inside of stored functions + or triggers as all such statements prohibited there. + */ + DBUG_ASSERT(! thd->in_sub_stmt); /* Commit or rollback the statement transaction. */ thd->is_error() ? trans_rollback_stmt(thd) : trans_commit_stmt(thd); /* Commit the normal transaction if one is active. */ -- cgit v1.2.1 From 6f1decbf7736a42b8eb08ac6c05bd300cc9df1d3 Mon Sep 17 00:00:00 2001 From: Marc Alff Date: Wed, 29 Jun 2011 10:15:05 +0200 Subject: Bug#12565712 - 61205: "QUERIES PER SECOND AVG" VALUE IN STATUS OUTPUT IS INCORRECT Before this fix, a server executing 1009 queries in 1000 seconds would give a status of: Queries per second avg: 1.9 The printf format used to print the decimal part, computed separately, is incorrect. With this fix, the correct result is printed: Queries per second avg: 1.009 Tested manually, no test case provided. --- sql/sql_parse.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/sql_parse.cc') diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index 36fdf376fa6..885db292699 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -1308,7 +1308,7 @@ bool dispatch_command(enum enum_server_command command, THD *thd, length= my_snprintf(buff, buff_len - 1, "Uptime: %lu Threads: %d Questions: %lu " "Slow queries: %lu Opens: %lu Flush tables: %lu " - "Open tables: %u Queries per second avg: %u.%u", + "Open tables: %u Queries per second avg: %u.%03u", uptime, (int) thread_count, (ulong) thd->query_id, current_global_status_var.long_query_count, -- cgit v1.2.1 From 44135d4725dd3ad6d331c60b0bab1618472b8ae4 Mon Sep 17 00:00:00 2001 From: Kent Boortz Date: Thu, 30 Jun 2011 17:31:31 +0200 Subject: Updated/added copyright headers --- sql/sql_parse.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/sql_parse.cc') diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index de67b99b172..c1a1ebf564a 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -11,7 +11,7 @@ You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software - Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ #define MYSQL_LEX 1 #include "mysql_priv.h" -- cgit v1.2.1 From 083a316d1f9020d48a5b9769fafbb3accad3c03a Mon Sep 17 00:00:00 2001 From: Tatjana Azundris Nuernberg Date: Tue, 12 Jul 2011 06:08:52 +0100 Subject: Bug#11758414/Bug#50614: Default storage_engine not honored when set from within a stored procedure When CREATE TABLE wasn't given ENGINE=... it would determine the default ENGINE at parse-time rather than at execution time, leading to incorrect behaviour (namely, later changes to the default engine being ignore) when calling CREATE TABLE from a stored procedure. We now defer working out the default engine till execution of CREATE TABLE. mysql-test/r/sp_trans.result: results! mysql-test/t/sp_trans.test: Show that CREATE TABLE (called from store routine) heeds any changes after CREATE SP / parse-time. Show that explicitly requesting an ENGINE still works. sql/sql_parse.cc: If no ENGINE=... was given at parse-time, determine default engine at execution time of CREATE TABLE. sql/sql_yacc.yy: If CREATE TABLE is not given ENGINE=..., don't bother figuring out the default engine during parsing; we'll do it at execution time instead to be aware of the latest updates. --- sql/sql_parse.cc | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'sql/sql_parse.cc') diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index 2eeabc2f0c1..14ad77d29fd 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -2616,6 +2616,12 @@ mysql_execute_command(THD *thd) create_table->table_name)) goto end_with_restore_list; #endif + /* + If no engine type was given, work out the default now + rather than at parse-time. + */ + if (!(create_info.used_fields & HA_CREATE_USED_ENGINE)) + create_info.db_type= ha_default_handlerton(thd); /* If we are using SET CHARSET without DEFAULT, add an implicit DEFAULT to not confuse old users. (This may change). -- cgit v1.2.1 From 586c0c0ef6e23c4ce3c63f796187178f15e7010a Mon Sep 17 00:00:00 2001 From: Rohit Kalhans Date: Thu, 29 Sep 2011 14:47:27 +0530 Subject: BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN|REPL] SEL Problem: The following statements can cause the slave to go out of sync if logged in statement format: INSERT IGNORE...SELECT INSERT ... SELECT ... ON DUPLICATE KEY UPDATE REPLACE ... SELECT UPDATE IGNORE : CREATE ... IGNORE SELECT CREATE ... REPLACE SELECT Background: Since the order of the rows returned by the SELECT statement or otherwise may differ on master and slave, therefore the above statements may cuase the salve to go out of sync with the master. Fix: Issue a warning when statements like the above are exectued and the bin-logging format is statement. If the logging format is mixed, use row based logging. Marking a statement as unsafe has been done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while parsing for a token has been done we cannot be sure if the parsing of the other tokens has been done as well. Six new warning messages has been added for each unsafe statement. binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments. ****** BUG#11758262 - 50439: MARK INSERT...SEL...ON DUP KEY UPD,REPLACE...SEL,CREATE...[IGN|REPL] SEL Problem: The following statements can cause the slave to go out of sync if logged in statement format: INSERT IGNORE...SELECT INSERT ... SELECT ... ON DUPLICATE KEY UPDATE REPLACE ... SELECT UPDATE IGNORE : CREATE ... IGNORE SELECT CREATE ... REPLACE SELECT Background: Since the order of the rows returned by the SELECT statement or otherwise may differ on master and slave, therefore the above statements may cuase the salve to go out of sync with the master. Fix: Issue a warning when statements like the above are exectued and the bin-logging format is statement. If the logging format is mixed, use row based logging. Marking a statement as unsafe has been done in the sql/sql_parse.cc instead of sql/sql_yacc.cc, because while parsing for a token has been done we cannot be sure if the parsing of the other tokens has been done as well. Six new warning messages has been added for each unsafe statement. binlog.binlog_unsafe.test has been updated to incoporate these additional unsafe statments. mysql-test/extra/rpl_tests/rpl_insert_duplicate.test: Test removed: Added the test to rpl.rpl_insert_ignore.test ****** Test removed: the test is redundant as the same is being tested in rpl.rpl_insert_ignore. mysql-test/extra/rpl_tests/rpl_insert_id.test: Warnings disabled for the unsafe statements. mysql-test/extra/rpl_tests/rpl_insert_ignore.test: 1. Disabled warnings while for unsafe statements 2. As INSERT...IGNORE is an unsafe statement, an insert ignore not changing any rows, will not be logged in the binary log, in the ROW and MIXED modes. It will however be logged in STATEMENT mode. mysql-test/r/commit_1innodb.result: updated result file ****** updated result file mysql-test/suite/binlog/r/binlog_stm_blackhole.result: Updated result file. mysql-test/suite/binlog/r/binlog_unsafe.result: updated result file mysql-test/suite/binlog/t/binlog_unsafe.test: added tests for the statements marked as unsafe. mysql-test/suite/rpl/r/rpl_insert_duplicate.result: File Removed :Result file of rpl_insert_duplicate, which has been removed. mysql-test/suite/rpl/r/rpl_insert_ignore.result: Added the content of rpl.rpl_insert_duplicate here. mysql-test/suite/rpl/r/rpl_insert_select.result: Result file removed as the corresponding test has beenn removed. mysql-test/suite/rpl/r/rpl_known_bugs_detection.result: Updated result file. mysql-test/suite/rpl/t/rpl_insert_duplicate.test: File Removed: this was a wrapper for rpl.rpl_insert_duplicate.test, which has been removed. mysql-test/suite/rpl/t/rpl_insert_select.test: File Removed: This test became redundant after this fix, This test showed how INSERT IGNORE...SELECT break replication, which has been handled in this fix. mysql-test/suite/rpl/t/rpl_known_bugs_detection.test: Since all the tests are statement based bugs are being tested, having mixed format forces the event to be written in row format. When the statement and causes the test to fail as certain known bugs do not occur when the even is logged in row format. sql/share/errmsg-utf8.txt: added 6 new Warning messages. ****** added 6 new Warning messages. sql/sql_lex.cc: Added 6 new error Identifier [ER_BINLOG_STMT_UNSAFEE_*] sql/sql_lex.h: Added 6 new BINLOG_STMT_UNSAFE_* enums to identify the type of unsafe statement dealt with in this bug. ****** Added 6 new BINLOG_STMT_UNSAFE_* enums to identify the type of unsafe statement dealt with in this bug. sql/sql_parse.cc: added check for specific queries and marked them as unsafe. ****** added check for specific queries and marked them as unsafe. --- sql/sql_parse.cc | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) (limited to 'sql/sql_parse.cc') diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index 4df77b5b15b..4fac64749e9 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -2386,6 +2386,19 @@ case SQLCOM_PREPARE: { select_result *result; + /* + CREATE TABLE...IGNORE/REPLACE SELECT... can be unsafe, unless + ORDER BY PRIMARY KEY clause is used in SELECT statement. We therefore + use row based logging if mixed or row based logging is available. + TODO: Check if the order of the output of the select statement is + deterministic. Waiting for BUG#42415 + */ + if(lex->ignore) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_CREATE_IGNORE_SELECT); + + if(lex->duplicates == DUP_REPLACE) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_CREATE_REPLACE_SELECT); + /* If: a) we inside an SP and there was NAME_CONST substitution, @@ -2720,6 +2733,16 @@ end_with_restore_list: DBUG_ASSERT(first_table == all_tables && first_table != 0); if (update_precheck(thd, all_tables)) break; + + /* + UPDATE IGNORE can be unsafe. We therefore use row based + logging if mixed or row based logging is available. + TODO: Check if the order of the output of the select statement is + deterministic. Waiting for BUG#42415 + */ + if (lex->ignore) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_UPDATE_IGNORE); + DBUG_ASSERT(select_lex->offset_limit == 0); unit->set_limit(select_lex); MYSQL_UPDATE_START(thd->query()); @@ -2886,6 +2909,23 @@ end_with_restore_list: DBUG_ASSERT(first_table == all_tables && first_table != 0); if ((res= insert_precheck(thd, all_tables))) break; + /* + INSERT...SELECT...ON DUPLICATE KEY UPDATE/REPLACE SELECT/ + INSERT...IGNORE...SELECT can be unsafe, unless ORDER BY PRIMARY KEY + clause is used in SELECT statement. We therefore use row based + logging if mixed or row based logging is available. + TODO: Check if the order of the output of the select statement is + deterministic. Waiting for BUG#42415 + */ + if (lex->sql_command == SQLCOM_INSERT_SELECT && + lex->duplicates == DUP_UPDATE) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_INSERT_SELECT_UPDATE); + + if (lex->sql_command == SQLCOM_INSERT_SELECT && lex->ignore) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_INSERT_IGNORE_SELECT); + + if (lex->sql_command == SQLCOM_REPLACE_SELECT) + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_REPLACE_SELECT); /* Fix lock for first table */ if (first_table->lock_type == TL_WRITE_DELAYED) -- cgit v1.2.1