An error occurred fetching the project authors.
- 04 Feb, 2010 1 commit
-
-
Konstantin Osipov authored
Cherry-pick a fix Bug#37148 from next-mr, to preserve file ids of the added files, and ensure that all the necessary changes have been pulled. Since initially Bug#37148 was null-merged into 6.0, the changeset that is now being cherry-picked was likewise null merged into next-4284. Now that Bug#37148 has been reapplied to 6.0, try to make it work with next-4284. This is also necessary to be able to pull other changes from 5.1-rep into next-4284. To resolve the merge issues use this changeset applied to 6.0: revid:jperkin@sun.com-20091216103628-ylhqf7s6yegui2t9 revno: 3776.1.1 committer: He Zhenxing <zhenxing.he@sun.com> branch nick: 6.0-codebase-bugfixing timestamp: Thu 2009-12-17 17:02:50 +0800 message: Fix merge problem with Bug#37148
-
- 01 Feb, 2010 1 commit
-
-
Dmitry Lenev authored
Add a wait-for graph based deadlock detector to the MDL subsystem. Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346 "innodb does not detect deadlock between update and alter table". The first bug manifested itself as an unwarranted abort of a transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER statement, when this transaction tried to repeat use of a table, which it has already used in a similar fashion before ALTER started. The second bug showed up as a deadlock between table-level locks and InnoDB row locks, which was "detected" only after innodb_lock_wait_timeout timeout. A transaction would start using the table and modify a few rows. Then ALTER TABLE would come in, and start copying rows into a temporary table. Eventually it would stumble on the modified records and get blocked on a row lock. The first transaction would try to do more updates, and get blocked on thr_lock.c lock. This situation of circular wait would only get resolved by a timeout. Both these bugs stemmed from inadequate solutions to the problem of deadlocks occurring between different locking subsystems. In the first case we tried to avoid deadlocks between metadata locking and table-level locking subsystems, when upgrading shared metadata lock to exclusive one. Transactions holding the shared lock on the table and waiting for some table-level lock used to be aborted too aggressively. We also allowed ALTER TABLE to start in presence of transactions that modify the subject table. ALTER TABLE acquires TL_WRITE_ALLOW_READ lock at start, and that block all writes against the table (naturally, we don't want any writes to be lost when switching the old and the new table). TL_WRITE_ALLOW_READ lock, in turn, would block the started transaction on thr_lock.c lock, should they do more updates. This, again, lead to the need to abort such transactions. The second bug occurred simply because we didn't have any mechanism to detect deadlocks between the table-level locks in thr_lock.c and row-level locks in InnoDB, other than innodb_lock_wait_timeout. This patch solves both these problems by moving lock conflicts which are causing these deadlocks into the metadata locking subsystem, thus making it possible to avoid or detect such deadlocks inside MDL. To do this we introduce new type-of-operation-aware metadata locks, which allow MDL subsystem to know not only the fact that transaction has used or is going to use some object but also what kind of operation it has carried out or going to carry out on the object. This, along with the addition of a special kind of upgradable metadata lock, allows ALTER TABLE to wait until all transactions which has updated the table to go away. This solves the second issue. Another special type of upgradable metadata lock is acquired by LOCK TABLE WRITE. This second lock type allows to solve the first issue, since abortion of table-level locks in event of DDL under LOCK TABLES becomes also unnecessary. Below follows the list of incompatible changes introduced by this patch: - From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those statements that acquire TL_WRITE_ALLOW_READ lock) wait for all transactions which has *updated* the table to complete. - From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE (i.e. all statements which acquire TL_WRITE table-level lock) wait for all transaction which *updated or read* from the table to complete. As a consequence, innodb_table_locks=0 option no longer applies to LOCK TABLES ... WRITE. - DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort statements or transactions which use tables being dropped or renamed, and instead wait for these transactions to complete. - Since LOCK TABLES WRITE now takes a special metadata lock, not compatible with with reads or writes against the subject table and transaction-wide, thr_lock.c deadlock avoidance algorithm that used to ensure absence of deadlocks between LOCK TABLES WRITE and other statements is no longer sufficient, even for MyISAM. The wait-for graph based deadlock detector of MDL subsystem may sometimes be necessary and is involved. This may lead to ER_LOCK_DEADLOCK error produced for multi-statement transactions even if these only use MyISAM: session 1: session 2: begin; update t1 ... lock table t2 write, t1 write; -- gets a lock on t2, blocks on t1 update t2 ... (ER_LOCK_DEADLOCK) - Finally, support of LOW_PRIORITY option for LOCK TABLES ... WRITE was abandoned. LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same priority as the usual LOCK TABLE ... WRITE. SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE in the wait queue. - We do not take upgradable metadata locks on implicitly locked tables. So if one has, say, a view v1 that uses table t1, and issues: LOCK TABLE v1 WRITE; FLUSH TABLE t1; -- (or just 'FLUSH TABLES'), an error is produced. In order to be able to perform DDL on a table under LOCK TABLES, the table must be locked explicitly in the LOCK TABLES list.
-
- 28 Jan, 2010 1 commit
-
-
Davi Arnaut authored
Rename method as to not hide a base. Reorder attributes initialization. Remove unused variable. Rework code to silence a warning due to assignment used as truth value.
-
- 25 Jan, 2010 1 commit
-
-
Mats Kindahl authored
-
- 24 Jan, 2010 1 commit
-
-
He Zhenxing authored
-
- 22 Jan, 2010 1 commit
-
-
Sergey Glukhov authored
removed wrongly introduced strlen calls
-
- 19 Jan, 2010 1 commit
-
-
Sergey Glukhov authored
added check_length optimization for I_S_NAME comparison
-
- 10 Dec, 2009 1 commit
-
-
Marc Alff authored
Part III: mysys instrumentation
-
- 09 Dec, 2009 1 commit
-
-
He Zhenxing authored
There are three issues that caused rpl_killed_ddl fails sporadically in pb2: 1) thd->clear_error() was not called before create Query event if operation is executed successfully. 2) DATABASE d2 might do exist because the statement to CREATE or ALTER it was killed 3) because of bug 43353, kill the query that do DROP FUNCTION or DROP PROCEDURE can result in SP not found This patch fixed all above issues by: 1) Called thd->clear_error() if the operation succeeded. 2) Add IF EXISTS to the DROP DATABASE d2 statement 3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.
-
- 02 Dec, 2009 1 commit
-
-
Konstantin Osipov authored
---------------------------------------------------------- revno: 2630.10.1 committer: Konstantin Osipov <konstantin@mysql.com> branch nick: mysql-6.0-lock-tables-tidyup timestamp: Wed 2008-06-11 15:49:58 +0400 message: WL#3726, review fixes. Now that we have metadata locks, we don't need to keep a crippled TABLE instance in the table cache to indicate that a table is locked. Remove all code that used this technique. Instead, rely on metadata locks and use the standard open_table() and close_thread_table() to manipulate with the table cache tables. Removes a list of functions that have become unused (see the comment for sql_base.cc for details). Under LOCK TABLES, keep a TABLE_LIST instance for each table that may be temporarily closed. For that, implement an own class for LOCK TABLES mode, Locked_tables_list. This is a pre-requisite patch for WL#4144. This is not exactly a backport: there is no new online ALTER table in Celosia, so the old alter table code was changed to work with the new table cache API.
-
- 01 Dec, 2009 1 commit
-
-
Konstantin Osipov authored
---------------------------------------------------------- revno: 2630.2.20 committer: Konstantin Osipov <konstantin@mysql.com> branch nick: mysql-6.0-runtime timestamp: Fri 2008-06-27 20:10:42 +0400 message: Fix a regression introduced by WL#3726 when a table was left in the table cache after DROP DATABASE. Implementation of DROP DATABASE reads a list of files in the database directory and constructs from it the list of tables to be dropped. If the filesystem is case-insensitive and case-preserving, the table names should be lowercased, because the same has been done when entries for them were inserted into the table cache. Skipping this step will lead to orphaned TABLEs left in the table cache. Fixes lowercase_table2 failure on powermacg5.
-
- 30 Nov, 2009 1 commit
-
-
Konstantin Osipov authored
Backport of: ------------------------------------------------------------ revno: 2630.4.1 committer: Dmitry Lenev <dlenev@mysql.com> branch nick: mysql-6.0-3726-w timestamp: Fri 2008-05-23 17:54:03 +0400 message: WL#3726 "DDL locking for all metadata objects". After review fixes in progress. ------------------------------------------------------------ This is the first patch in series. It transforms the metadata locking subsystem to use a dedicated module (mdl.h,cc). No significant changes in the locking protocol. The import passes the test suite with the exception of deprecated/removed 6.0 features, and MERGE tables. The latter are subject to a fix by WL#4144. Unfortunately, the original changeset comments got lost in a merge, thus this import has its own (largely insufficient) comments. This patch fixes Bug#25144 "replication / binlog with view breaks". Warning: this patch introduces an incompatible change: Under LOCK TABLES, it's no longer possible to FLUSH a table that was not locked for WRITE. Under LOCK TABLES, it's no longer possible to DROP a table or VIEW that was not locked for WRITE. ****** Backport of: ------------------------------------------------------------ revno: 2630.4.2 committer: Dmitry Lenev <dlenev@mysql.com> branch nick: mysql-6.0-3726-w timestamp: Sat 2008-05-24 14:03:45 +0400 message: WL#3726 "DDL locking for all metadata objects". After review fixes in progress. ****** Backport of: ------------------------------------------------------------ revno: 2630.4.3 committer: Dmitry Lenev <dlenev@mysql.com> branch nick: mysql-6.0-3726-w timestamp: Sat 2008-05-24 14:08:51 +0400 message: WL#3726 "DDL locking for all metadata objects" Fixed failing Windows builds by adding mdl.cc to the lists of files needed to build server/libmysqld on Windows. ****** Backport of: ------------------------------------------------------------ revno: 2630.4.4 committer: Dmitry Lenev <dlenev@mysql.com> branch nick: mysql-6.0-3726-w timestamp: Sat 2008-05-24 21:57:58 +0400 message: WL#3726 "DDL locking for all metadata objects". Fix for assert failures in kill.test which occured when one tried to kill ALTER TABLE statement on merge table while it was waiting in wait_while_table_is_used() for other connections to close this table. These assert failures stemmed from the fact that cleanup code in this case assumed that temporary table representing new version of table was open with adding to THD::temporary_tables list while code which were opening this temporary table wasn't always fulfilling this. This patch changes code that opens new version of table to always do this linking in. It also streamlines cleanup process for cases when error occurs while we have new version of table open. ****** WL#3726 "DDL locking for all metadata objects" Add libmysqld/mdl.cc to .bzrignore. ****** Backport of: ------------------------------------------------------------ revno: 2630.4.6 committer: Dmitry Lenev <dlenev@mysql.com> branch nick: mysql-6.0-3726-w timestamp: Sun 2008-05-25 00:33:22 +0400 message: WL#3726 "DDL locking for all metadata objects". Addition to the fix of assert failures in kill.test caused by changes for this worklog. Make sure we close the new table only once.
-
- 24 Nov, 2009 1 commit
-
-
Konstantin Osipov authored
---------------------------------------------------------------------- ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0 Bug#32082 : definition of VOID in my_global.h conflicts with Windows SDK headers VOID macro is now removed. Its usage is replaced with void cast. In some cases, where cast does not make much sense (pthread_*, printf, hash_delete, my_seek), cast is ommited.
-
- 21 Nov, 2009 1 commit
-
-
He Zhenxing authored
This is the non-ndb part of the patch. The return value of mysql_bin_log.write was ignored by most callers, which may lead to inconsistent on master and slave if the transaction was committed while the binlog was not correctly written. If my_error() is call in mysql_bin_log.write, this could also lead to assertion issue if my_ok() or my_error() is called after. This fixed the problem by let the caller to check and handle the return value of mysql_bin_log.write. This patch only adresses the simple cases.
-
- 03 Nov, 2009 1 commit
-
-
Alfranio Correia authored
Non-transactional updates that take place inside a transaction present problems for logging because they are visible to other clients before the transaction is committed, and they are not rolled back even if the transaction is rolled back. It is not always possible to log correctly in statement format when both transactional and non-transactional tables are used in the same transaction. In the current patch, we ensure that such scenario is completely safe under the ROW and MIXED modes.
-
- 16 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
Implemented the server infrastructure for the fix: 1. Added a function LEX_STRING *thd_query_string(THD) to return a LEX_STRING structure instead of char *. This is the function that must be called in innodb instead of thd_query() 2. Did some encapsulation in THD : aggregated thd_query and thd_query_length into a LEX_STRING and made accessor and mutator methods for easy code updating. 3. Updated the server code to use the new methods where applicable.
-
- 14 Oct, 2009 1 commit
-
-
Konstantin Osipov authored
---------------------------------------------------------- revno: 2617.22.5 committer: Konstantin Osipov <kostja@sun.com> branch nick: mysql-6.0-runtime timestamp: Tue 2009-01-27 05:08:48 +0300 message: Remove non-prefixed use of HASH. Always use my_hash_init(), my_hash_inited(), my_hash_search(), my_hash_element(), my_hash_delete(), my_hash_free() rather than non-prefixed counterparts (hash_init(), etc). Remove the backward-compatible defines.
-
- 07 Oct, 2009 1 commit
-
-
Alexander Nozdrin authored
Original revision is from mysql-6.0-codebase: revno: 2630.3.1 committer: Alexander Nozdrin <alik@mysql.com> branch nick: 6.0-rt-bug26704 timestamp: Thu 2008-05-29 21:04:06 +0400 message: A fix for Bug#26704: Failing DROP DATABASE brings mysql-client out of sync. The problem was that we changed current database w/o caring whether it was dropped successfully or not. The fix is not to change current database if we failed to drop it.
-
- 23 Sep, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 Cleaning up warnings not present in 5.0.
-
- 17 Sep, 2009 1 commit
-
-
Sergey Glukhov authored
additional backport of of bug43138 fix
-
- 13 Aug, 2009 1 commit
-
-
There is an inconsistency with DROP DATABASE|TABLE|EVENT IF EXISTS and CREATE DATABASE|TABLE|EVENT IF NOT EXISTS. DROP IF EXISTS statements are binlogged even if either the DB, TABLE or EVENT does not exist. In contrast, Only the CREATE EVENT IF NOT EXISTS is binlogged when the EVENT exists. This patch fixes the following cases for all the replication formats: CREATE DATABASE IF NOT EXISTS. CREATE TABLE IF NOT EXISTS, CREATE TABLE IF NOT EXISTS ... LIKE, CREAET TABLE IF NOT EXISTS ... SELECT.
-
- 19 Jun, 2009 1 commit
-
-
Sergey Glukhov authored
The problem: described in the bug report. The fix: --increase buffers where it's necessary (buffers which are used in stxnmov) --decrease buffer lengths which are used
-
- 30 May, 2009 1 commit
-
-
He Zhenxing authored
Make the caller of Query_log_event, Execute_load_log_event constructors and THD::binlog_query to provide the error code instead of having the constructors to figure out the error code.
-
- 27 Mar, 2009 1 commit
-
-
He Zhenxing authored
When the thread executing a DDL was killed after finished its execution but before writing the binlog event, the error code in the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED. This patch fixed the problem by ignoring the kill status when constructing the event for DDL statements. This patch also included the following changes in order to provide the test case. 1) modified mysqltest to support variable for connection command 2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to run mysql client against the slave mysqld.
-
- 10 Feb, 2009 1 commit
-
-
Ignacio Galarza authored
- Remove bothersome warning messages. This change focuses on the warnings that are covered by the ignore file: support-files/compiler_warnings.supp. - Strings are guaranteed to be max uint in length
-
- 12 Jan, 2009 1 commit
-
-
Joerg Bruehe authored
Bug #40021: Renaming view fails, archived .frm for view is missing after downgrade Original changeset: > revision-id: gshchepa@mysql.com-20081114172557-xh0jlzwal8ze3cy6 > parent: ramil@mysql.com-20081114074229-vj4fvfrpmz8jfub9 > committer: Gleb Shchepa <gshchepa@mysql.com> > branch nick: mysql-5.0-bugteam > timestamp: Fri 2008-11-14 21:25:57 +0400
-
- 14 Nov, 2008 1 commit
-
-
Gleb Shchepa authored
missing after downgrade Obsolete arc/ directory and view .frm file backup support has been removed by the patch for bug 17823. However, that bugfix caused a problem with "live downgrades" of the server: if we rename some view 4 times under 5.1.29/5.0.72 and then try to rename it under 5.1.28/5.0.70 on the same database, the server fails with a error: query 'RENAME TABLE ... TO ...' failed: 6: Error on delete of '....frm-0001' (Errcode: 2) Also .frm file of that view may be lost (renamed to .frm~). The server failed because it tried to rename latest 3 backup .frm files renaming the view: the server used an integer value of the "revision" field of .frm file to extract those file names. After the fix for bug 17823 those files were not created/maintained any more, however the "revision" field was incremented as usual. So, the server failed renaming non existent files. This fix solves the problem by removing the support for "revision" .frm file field: 1. New server silently ignores existent "revision" fields in old .frm files and never write it down; 2. Old server assumes, that missing "revision" field in new .frm files means default value of 0. 3. Accordingly to the fix for bug 17823 the new server drops arc/ directory on alter/rename view, so after "live downgrade" old server begins maintenance of the arc/ directory from scratch without conflicts with .frm files.
-
- 30 Sep, 2008 1 commit
-
-
Gleb Shchepa authored
Server created "arc" directories inside database directories and maintained there useless copies of .frm files. Creation and renaming procedures of those copies as well as creation of "arc" directories has been discontinued. Removal procedure has been kept untouched to be able to cleanup existent database directories by the DROP DATABASE query. Also view renaming procedure has been updated to remove these directories.
-
- 27 Aug, 2008 1 commit
-
-
Mats Kindahl authored
tables open When executing a DROP DATABASE statement in ROW mode and having temporary tables open at the same time, the existance of temporary tables prevent the server from switching back to row mode after temporarily switching to statement mode to handle the logging of the statement. Fixed the problem by removing the code to switch to statement mode and added code to temporarily disable the binary log while dropping the objects in the database.
-
- 20 Aug, 2008 1 commit
-
-
Mats Kindahl authored
When executing a DROP DATABASE statement in ROW mode and having temporary tables open at the same time, the existance of temporary tables prevent the server from switching back to row mode after temporarily switching to statement mode to handle the logging of the statement. Fixed the problem by removing the code to switch to statement mode and added code to temporarily disable the binary log while dropping the objects in the database.
-
- 09 May, 2008 1 commit
-
-
thek@adventure.(none) authored
The event scheduler was not designed to work in embedded mode. This patch disables and excludes the event scheduler when the server is compiled for embedded build.
-
- 21 Mar, 2008 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
The bool data type was redefined to BOOL (4 bytes on windows). Removed the #define and fixed some of the warnings that were uncovered by this. Note that the fix also disables 2 warnings : 4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning) 4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation These warnings will be handled in a separate bug, as they are performance related or bogus. Fixed to int the return type of functions that return more than 2 distinct values.
-
- 12 Mar, 2008 1 commit
-
-
cmiller@zippy.cornsilk.net authored
table with backticks (Thanks to Lu Jingdong, though I did not take his patch directly, as it contained a significant flaw.) It wasn't a backtick/parsing problem. We merely didn't anticipate and allocate enough space to handle the optional "#mysql50#" table- name prefix. Now, allocate that extra space in case we need it when we look up a legacy table to get its file's name.
-
- 19 Feb, 2008 1 commit
-
-
kostja@dipika.(none) authored
does not send it to the client.
-
- 12 Dec, 2007 1 commit
-
-
kostja@bodhi.(none) authored
cause ROLLBACK of statement", part 1. Review fixes. Do not send OK/EOF packets to the client until we reached the end of the current statement. This is a consolidation, to keep the functionality that is shared by all SQL statements in one place in the server. Currently this functionality includes: - close_thread_tables() - log_slow_statement(). After this patch and the subsequent patch for Bug#12713, it shall also include: - ha_autocommit_or_rollback() - net_end_statement() - query_cache_end_of_result(). In future it may also include: - mysql_reset_thd_for_next_command().
-
- 26 Nov, 2007 1 commit
-
-
strmake() called with wrong parameters: 5.1-specific fixes.
-
- 23 Nov, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
disable decoding of table name if the table is internal temporary table
-
- 16 Nov, 2007 1 commit
-
-
mkindahl@dl145h.mysql.com authored
DROP DATABASE statement writes changes to mysql.proc table under RBR When replicating a DROP DATABASE statement with a database holding stored procedures, the changes to the mysql.proc table was recorded in the binary log under row-based replication. With this patch, the thread uses statement-logging format for the duration of the DROP DATABASE statement. The logging format is (already) reset at the end of the statement, so no additional code for resetting the logging format is necessary.
-
- 10 Sep, 2007 1 commit
-
-
malff@lambda.weblab authored
UPGRADE) Bug 17565 (RENAME DATABASE destroys events) Bug#28360 (RENAME DATABASE destroys routines) Removed the RENAME DATABASE db1 TO db2 statement. Implemented the ALTER DATABASE db UPGRADE DATA DIRECTORY NAME statement, which has the same function.
-
- 31 Aug, 2007 1 commit
-
-
anozdrin/alik@ibm.opbmk authored
of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE.
-