An error occurred fetching the project authors.
- 07 Mar, 2011 1 commit
-
-
Jon Olav Hauglid authored
FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads to assert failure. This assert was triggered if a statement tried up upgrade a metadata lock with an active FLUSH TABLE <list> WITH READ LOCK. The assert checks that the connection already holds a global intention exclusive metadata lock. However, FLUSH TABLE <list> WITH READ LOCK does not acquire this lock in order to be compatible with FLUSH TABLES WITH READ LOCK. Therefore any metadata lock upgrade caused the assert to be triggered. This patch fixes the problem by preventing metadata lock upgrade if the connection has an active FLUSH TABLE <list> WITH READ LOCK. ER_TABLE_NOT_LOCKED_FOR_WRITE will instead be reported to the client. Test case added to flush.test.
-
- 25 Jan, 2011 1 commit
-
-
Karen Langford authored
-
- 11 Jan, 2011 1 commit
-
-
Jan Wedvik authored
to crash mysqld". handler::pushed_cond was not always properly reset when table objects where recycled via the table cache. handler::pushed_cond is now set to NULL in handler::ha_reset(). This should prevent pushed conditions from (incorrectly) re-apperaring in later queries.
-
- 28 Dec, 2010 1 commit
-
-
Kent Boortz authored
- Removed files specific to compiling on OS/2 - Removed files specific to SCO Unix packaging - Removed "libmysqld/copyright", text is included in documentation - Removed LaTeX headers for NDB Doxygen documentation - Removed obsolete NDB files - Removed "mkisofs" binaries - Removed the "cvs2cl.pl" script - Changed a few GPL texts to use "program" instead of "library"
-
- 16 Dec, 2010 1 commit
-
-
Jon Olav Hauglid authored
temptable views The TABLE::key_read field indicates if the optimizer has found that row retrieval only should access the index tree. The triggered assert inside close_thread_table() checks that this field has been reset when the table is about to be closed. During normal execution, these fields are reset right before tables are closed at the end of mysql_execute_command(). But in the case of errors, tables are closed earlier. The patch for Bug#52044 refactored the open tables code so that close_thread_tables() is called immediately if opening of tables fails. At this point in the execution, it could happend that all TABLE::key_read fields had not been properly reset, therefore triggering the assert. The problematic statement in this case was EXPLAIN where the query accessed two derived tables and where the first derived table was processed successfully while the second derived table was not. Since it was an EXPLAIN, TABLE::key_read fields were not reset after successful derived table processing since the state needs to be accessible afterwards. When processing of the second derived table failed, it's corresponding SELECT_LEX_UNIT was cleaned, which caused it's TABLE::key_read fields to be reset. Since processing failed, the error path of open_and_lock_tables() was entered and close_thread_tables() was called. The assert was then triggered due to the TABLE::key_read fields set during processing of the first derived table. This patch fixes the problem by adding a new derived table processor, mysql_derived_cleanup() that is called after mysql_derived_filling(). It causes cleanup of all SELECT_LEX_UNITs to be called, resetting all relevant TABLE::key_read fields. Test case added to derived.test.
-
- 15 Dec, 2010 1 commit
-
-
Alexander Nozdrin authored
The user-visible problem was that changes to column-level privileges, happened in between of PREPARE and EXECUTE of a prepared statement, were neglected. I.e. a prepared statement could be executed with the column-level privileges as of PREPARE-time. The problem existed for column-level privileges only. A similar problem existed for stored programs: the changes between executions didn't have an effect. Technically the thing is that table references are cached in Prepared_statement::prepare() call. In subsequent Prepared_statement::execute() calls those cached values are used. There are two functions to get a field by name: find_field_in_table() and find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is called, on execute-phase -- find_field_in_table() because the table is cached. find_field_in_table() does not check column-level privileges and expects the caller to do that. The problem was that this check was forgotten. The fix is to check them there as it happens in find_field_in_table_ref().
-
- 11 Nov, 2010 1 commit
-
-
Dmitry Lenev authored
bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ LOCK" and bug #54673 "It takes too long to get readlock for 'FLUSH TABLES WITH READ LOCK'". The first bug manifested itself as a deadlock which occurred when a connection, which had some table open through HANDLER statement, tried to update some data through DML statement while another connection tried to execute FLUSH TABLES WITH READ LOCK concurrently. What happened was that FTWRL in the second connection managed to perform first step of GRL acquisition and thus blocked all upcoming DML. After that it started to wait for table open through HANDLER statement to be flushed. When the first connection tried to execute DML it has started to wait for GRL/the second connection creating deadlock. The second bug manifested itself as starvation of FLUSH TABLES WITH READ LOCK statements in cases when there was a constant stream of concurrent DML statements (in two or more connections). This has happened because requests for protection against GRL which were acquired by DML statements were ignoring presence of pending GRL and thus the latter was starved. This patch solves both these problems by re-implementing GRL using metadata locks. Similar to the old implementation acquisition of GRL in new implementation is two-step. During the first step we block all concurrent DML and DDL statements by acquiring global S metadata lock (each DML and DDL statement acquires global IX lock for its duration). During the second step we block commits by acquiring global S lock in COMMIT namespace (commit code acquires global IX lock in this namespace). Note that unlike in old implementation acquisition of protection against GRL in DML and DDL is semi-automatic. We assume that any statement which should be blocked by GRL will either open and acquires write-lock on tables or acquires metadata locks on objects it is going to modify. For any such statement global IX metadata lock is automatically acquired for its duration. The first problem is solved because waits for GRL become visible to deadlock detector in metadata locking subsystem and thus deadlocks like one in the first bug become impossible. The second problem is solved because global S locks which are used for GRL implementation are given preference over IX locks which are acquired by concurrent DML (and we can switch to fair scheduling in future if needed). Important change: FTWRL/GRL no longer blocks DML and DDL on temporary tables. Before this patch behavior was not consistent in this respect: in some cases DML/DDL statements on temporary tables were blocked while in others they were not. Since the main use cases for FTWRL are various forms of backups and temporary tables are not preserved during backups we have opted for consistently allowing DML/DDL on temporary tables during FTWRL/GRL. Important change: This patch changes thread state names which are used when DML/DDL of FTWRL is waiting for global read lock. It is now either "Waiting for global read lock" or "Waiting for commit lock" depending on the stage on which FTWRL is. Incompatible change: To solve deadlock in events code which was exposed by this patch we have to replace LOCK_event_metadata mutex with metadata locks on events. As result we have to prohibit DDL on events under LOCK TABLES. This patch also adds extensive test coverage for interaction of DML/DDL and FTWRL. Performance of new and old global read lock implementations in sysbench tests were compared. There were no significant difference between new and old implementations.
-
- 14 Oct, 2010 2 commits
-
-
Konstantin Osipov authored
sql_show.cc during rqg_info_schema test on Windows". Ensure we do not access freed memory when filling information_schema.views when one of the views could not be properly opened.
-
Jon Olav Hauglid authored
|| thd->in_sub_stmt || (thd->state.. Don't rollback statement transactions if we are in a sub-statement. This could for example happen for open_ltable() when opening the general log during execution of a stored procedure.
-
- 13 Oct, 2010 1 commit
-
-
Jon Olav Hauglid authored
thd->in_sub_stmt || (thd->state.. OPTIMIZE TABLE is not directly supported by InnoDB. Instead, recreate and analyze of the table is done. After recreate, the table is closed and locks are released before the table is reopened and locks re-acquired for the analyze phase. This assertion was triggered if OPTIMIZE TABLE failed to acquire thr_lock locks before starting the analyze phase. The assertion tests (among other things) that there no active statement transaction. However, as part of acquiring the thr_lock lock, external_lock() is called for InnoDB tables and this causes a statement transaction to be started. If thr_multi_lock() later fails (e.g. due to timeout), the failure handling code causes this assert to be triggered. This patch fixes the problem by doing rollback of the current statement transaction in case open_ltable (used by OPTIMIZE TABLE) fails to acquire thr_lock locks. Test case added to lock_sync.test.
-
- 11 Oct, 2010 1 commit
-
-
After ALTER TABLE which changed only table's metadata, row-based binlog sometimes got corrupted since the tablemap was unexpectedly set to 0 for subsequent updates to the same table. ALTER TABLE which changed only table's metadata always reset table_map_id for the table share to 0. Despite the fact that 0 is a valid value for table_map_id, this step caused problems as it could have created situation in which we had more than one table share with table_map_id equal 0. If more than one table with table_map_id are 0 were updated in the same statement, updates to these different tables were written into the same rows event. This caused slave server to crash. This bug happens only on 5.1. It doesn't affect 5.5+. This patch solves this problem by ensuring that ALTER TABLE statements which change metadata only never reset table_map_id to 0. To do this it changes reopen_table() to correctly use refreshed table_map_id value instead of using the old one/ resetting it.
-
- 30 Sep, 2010 1 commit
-
-
Dmitry Lenev authored
in the MDL deadlock detector". It is no longer needed as a better fix for this bug has been pushed.
-
- 24 Sep, 2010 1 commit
-
-
Dmitry Lenev authored
argument of inline_mysql_mutex_init in sql_base.cc. When initializing LOCK_dd_owns_lock_open mutex pass correct PSI key instead of NULL value.
-
- 15 Sep, 2010 1 commit
-
-
Dmitry Lenev authored
tables". Attempting to issue an INSERT DELAYED statement for a MERGE table might have caused a deadlock if it happened as part of a transaction or under LOCK TABLES, and there was a concurrent DDL or LOCK TABLES ... WRITE statement which tried to lock one of its underlying tables. The problem occurred when a delayed insert handler thread tried to open a MERGE table and discovered that to do this it had also to open all underlying tables and hence acquire metadata locks on them. Since metadata locks on the underlying tables were not pre-acquired by the connection thread executing INSERT DELAYED, attempts to do so might lead to waiting. In this case the connection thread had to wait for the delayed insert thread. If the thread which was preventing the lock on the underlying table from being acquired had to wait for the connection thread (due to this or other metadata locks), a deadlock occurred. This deadlock was not detected by the MDL deadlock detector since waiting for the handler thread by the connection thread is not represented in the wait-for graph. This patch solves the problem by ensuring that the delayed insert handler thread never tries to open underlying tables of a MERGE table. Instead open_tables() is aborted right after the parent table is opened and a ER_DELAYED_NOT_SUPPORTED error is emitted (which is passed to the connection thread and ultimately to the user).
-
- 09 Sep, 2010 1 commit
-
-
Dmitry Lenev authored
table causes assert failure". Attempting to use FLUSH TABLE table_list WITH READ LOCK statement for a MERGE table led to an assertion failure if one of its children was not present in the list of tables to be flushed. The problem was not visible in non-debug builds. The assertion failure was caused by the fact that in such situations FLUSH TABLES table_list WITH READ LOCK implementation tried to use (e.g. lock) such child tables without acquiring metadata lock on them. This happened because when opening tables we assumed metadata locks on all tables were already acquired earlier during statement execution and a such assumption was false for MERGE children. This patch fixes the problem by ensuring at open_tables() time that we try to acquire metadata locks on all tables to be opened. For normal tables such requests are satisfied instantly since locks are already acquired for them. For MERGE children metadata locks are acquired in normal fashion. Note that FLUSH TABLES merge_table WITH READ LOCK will lock for read both the MERGE table and its children but will flush only the MERGE table. To flush children one has to mention them in table list explicitly. This is expected behavior and it is consistent with usage patterns for this statement (e.g. in mysqlhotcopy script).
-
- 06 Sep, 2010 1 commit
-
-
Dmitry Lenev authored
MDL deadlock detector". Deadlock could have occurred when workload containing mix of DML, DDL and FLUSH TABLES statements affecting same set of tables was executed in heavily concurrent environment. This deadlock occurred when several connections tried to perform deadlock detection in metadata locking subsystem. The first connection started traversing wait-for graph, encountered sub-graph representing wait for flush, acquired LOCK_open and dived into sub-graph inspection. When it has encounterd sub-graph corresponding to wait for metadata lock and blocked while trying to acquire rd-lock on MDL_lock::m_rwlock (*) protecting this subgraph, since some other thread had wr-lock on it. When this wr-lock was released it could have happened (if there was other pending wr-lock against this rwlock) that rd-lock from the first connection was left unsatisfied but at the same time new rd-lock request from the second connection sneaked in and was satisfied (for this to be possible second rd- request should come exactly after wr-lock is released but before pending wr-lock manages to grab rwlock, which is possible both on Linux and in our own rwlock implementation). If this second connection continued traversing wait-for graph and encountered sub-graph representing wait for flush it tried to acquire LOCK_open and thus deadlock was created. This patch tries to workaround this problem but not allowing deadlock detector to lock LOCK_open mutex if some other thread doing deadlock detection already owns it and current search depth is greater than 0. Instead deadlock is reported. Other possible solutions are either known to have negative effects on performance or require much more time for proper implementation and testing. No test case is provided as this bug is very hard to repeat in MTR environment but is repeatable with the help of RQG tests.
-
- 31 Aug, 2010 2 commits
-
-
Alexander Nozdrin authored
to allow temp table operations) -- prerequisite patch #3. Rename open_temporary_table() to open_table_uncached(). open_temporary_table() will be introduced in following patches to open temporary tables for a statement.
-
Alexander Nozdrin authored
to allow temp table operations) -- prerequisite patch #2. Introduce a new form of find_temporary_table() function: find_temporary_table() by a table key. It will be used in further patches. Replace find_temporary_table(table_list->db, table_list->name) by more appropiate find_temporary_table(table_list) across the codebase.
-
- 27 Aug, 2010 1 commit
-
-
Alexander Nozdrin authored
to allow temp table operations) -- prerequisite patch #1. Move a piece of code that initialiazes TABLE instance after it was successfully opened into a separate function. This function will be reused in the following patches.
-
- 20 Aug, 2010 2 commits
-
-
Jon Olav Hauglid authored
on CREATE TABLE .. SELECT I_S.PART This assert was triggered if an InnoDB table was created using CREATE TABLE ... AS SELECT where the query used an I_S table, and a view existed in the database. It would also be triggered for any statement changing an InnoDB table (e.g. INSERT, UPDATE, DELETE) which had a subquery referencing an I_S table. The assert was triggered if open_normal_and_derived_tables() failed and a statement transaction had been started. This will usually not happen as tables are opened before a statement transaction is started. However, e.g. CREATE TABLE ... AS SELECT starts a transaction in order to insert tuples into the new table. And if the subquery references an I_S table, all current tables and views can be opened in order to fill the I_S table on the fly. If a view is discovered, open will fail as it is instructed to open tables only (OPEN_TABLE_ONLY). This would cause the assert to be triggered. The assert was added in the patch for Bug#52044 and was therefore not in any released versions of the server. This patch fixes the problem by adjusting the assert to take into consideration the possibility of tables being opened as part of an I_S query. This is similar to what is already done for close_tables_for_reopen(). Test case added to information_schema_inno.test.
-
Alfranio Correia authored
temp table This patch introduces two key changes in the replication's behavior. Firstly, it reverts part of BUG#51894 which puts any update to temporary tables into the trx-cache. Now, updates to temporary tables are handled according to the type of their engines as a regular table. Secondly, an unsafe mixed statement, (i.e. a statement that access transactional table as well non-transactional or temporary table, and writes to any of them), are written into the trx-cache in order to minimize errors in the execution when the statement logging format is in use. Such changes has a direct impact on which statements are classified as unsafe statements and thus part of BUG#53259 is reverted.
-
- 19 Aug, 2010 1 commit
-
-
Jon Olav Hauglid authored
check_if_table_exists() This assert was triggered when the server tried to load plugins while running in embedded server mode. In embedded server mode, check_if_table_exists() was used to check if mysql.plugin existed so that ER_NO_SUCH_TABLE could be silently ignored. The problem was that this check was done without acquiring a metadata lock on mysql.plugin first. This triggered the assert. This patch fixes the problem by removing the call to check_if_table_exists() from plugin_load(). Instead an error handler which traps ER_NO_SUCH_TABLE is installed before trying to open mysql.plugin when running in embedded server mode. No test coverage added since this assert was triggered by existing tests running in embedded server mode.
-
- 18 Aug, 2010 1 commit
-
-
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear automatically after the this patch. BUG#55617 is fixed by this patch too. This is the 5.5 part. It implements: - 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert anything and binlog anything if the table already exists. It only generate a warning that table already exists. - A couple of test cases for the behavior changing.
-
- 13 Aug, 2010 1 commit
-
-
Mattias Jonsson authored
corruption on ADD PARTITION and LOCK TABLE Bug#53770: Server crash at handler.cc:2076 on LOAD DATA after timed out COALESCE PARTITION 5.5 fix for: Bug#51042: REORGANIZE PARTITION can leave table in an inconsistent state in case of crash Needs to be back-ported to 5.1 5.5 fix for: Bug#50418: DROP PARTITION does not interact with transactions Main problem was non-persistent operations done before meta-data lock was taken (53770+53676). And 53676 needed to keep the table/partitions opened and locked while copying the data to the new partitions. Also added thorough tests to spot some additional bugs in the ddl_log code, which could result in bad state between the .frm and partitions. Collapsed patch, includes all fixes required from the reviewers.
-
- 12 Aug, 2010 1 commit
-
-
Konstantin Osipov authored
-
- 10 Aug, 2010 1 commit
-
-
Konstantin Osipov authored
Implement a few simple asserts in my_rwlock_t locks.
-
- 09 Aug, 2010 1 commit
-
-
Konstantin Osipov authored
Remove acquisition of LOCK_open around file system operations, since such operations are now protected by metadata locks. Rework table discovery algorithm to not require LOCK_open. No new tests added since all MDL locking operations are covered in lock.test and mdl_sync.test, and as long as these tests pass despite the increased concurrency, consistency must be unaffected.
-
- 06 Aug, 2010 1 commit
-
-
Dmitry Lenev authored
FLUSH TABLES <list> WITH READ LOCK are incompatible" to be pushed as separate patch. Replaced thread state name "Waiting for table", which was used by threads waiting for a metadata lock or table flush, with a set of names which better reflect types of resources being waited for. Also replaced "Table lock" thread state name, which was used by threads waiting on thr_lock.c table level lock, with more elaborate "Waiting for table level lock", to make it more consistent with other thread state names. Updated test cases and their results according to these changes. Fixed sys_vars.query_cache_wlock_invalidate_func test to not to wait for timeout of wait_condition.inc script.
-
- 04 Aug, 2010 1 commit
-
-
Konstantin Osipov authored
-
- 27 Jul, 2010 2 commits
-
-
Dmitry Lenev authored
TABLES <list> WITH READ LOCK are incompatible". The problem was that FLUSH TABLES <list> WITH READ LOCK which was issued when other connection has acquired global read lock using FLUSH TABLES WITH READ LOCK was blocked and has to wait until global read lock is released. This issue stemmed from the fact that FLUSH TABLES <list> WITH READ LOCK implementation has acquired X metadata locks on tables to be flushed. Since these locks required acquiring of global IX lock this statement was incompatible with global read lock. This patch addresses problem by using SNW metadata type of lock for tables to be flushed by FLUSH TABLES <list> WITH READ LOCK. It is OK to acquire them without global IX lock as long as we won't try to upgrade those locks. Since SNW locks allow concurrent statements using same table FLUSH TABLE <list> WITH READ LOCK now has to wait until old versions of tables to be flushed go away after acquiring metadata locks. Since such waiting can lead to deadlock MDL deadlock detector was extended to take into account waits for flush and resolve such deadlocks. As a bonus code in open_tables() which was responsible for waiting old versions of tables to go away was refactored. Now when we encounter old version of table in open_table() we don't back-off and wait for all old version to go away, but instead wait for this particular table to be flushed. Such approach supported by deadlock detection should reduce number of scenarios in which FLUSH TABLES aborts concurrent multi-statement transactions. Note that active FLUSH TABLES <list> WITH READ LOCK still blocks concurrent FLUSH TABLES WITH READ LOCK statement as the former keeps tables open and thus prevents the latter statement from doing flush.
-
Konstantin Osipov authored
This patch also fixes Bug#55452 "SET PASSWORD is replicated twice in RBR mode". The goal of this patch is to remove the release of metadata locks from close_thread_tables(). This is necessary to not mistakenly release the locks in the course of a multi-step operation that involves multiple close_thread_tables() or close_tables_for_reopen(). On the same token, move statement commit outside close_thread_tables(). Other cleanups: Cleanup COM_FIELD_LIST. Don't call close_thread_tables() in COM_SHUTDOWN -- there are no open tables there that can be closed (we leave the locked tables mode in THD destructor, and this close_thread_tables() won't leave it anyway). Make open_and_lock_tables() and open_and_lock_tables_derived() call close_thread_tables() upon failure. Remove the calls to close_thread_tables() that are now unnecessary. Simplify the back off condition in Open_table_context. Streamline metadata lock handling in LOCK TABLES implementation. Add asserts to ensure correct life cycle of statement transaction in a session. Remove a piece of dead code that has also become redundant after the fix for Bug 37521.
-
- 22 Jul, 2010 1 commit
-
-
Luis Soares authored
sporadically There are two problems: 1. When closing temporary tables, during the THD clean up - and after the session connection was already closed, there is a chance we can push an error into the THD diagnostics area, if the writing of the implicit DROP event to the binary log fails for some reason. As a consequence an assertion can be triggered, because at that point the diagnostics area is already set. 2. Using push_warning with MYSQL_ERROR::WARN_LEVEL_ERROR is a bug. Given that close_temporary_tables is mostly called from THD::cleanup - ie, with the session already closed, we fix problem #1 by allowing the diagnostics area to be overwritten. There is one other place in the code that calls close_temporary_tables - while applying Start_log_event_v3. To cover that case, we make close_temporary_tables to return the error, thus, propagating upwards in the stack. To fix problem #2, we replace push_warning with sql_print_error.
-
- 20 Jul, 2010 1 commit
-
-
Davi Arnaut authored
Fix warnings flagged by the new warning option -Wunused-but-set-variable that was added to GCC 4.6 and that is enabled by -Wunused and -Wall. The option causes a warning whenever a local variable is assigned to but is later unused. It also warns about meaningless pointer dereferences.
-
- 13 Jul, 2010 1 commit
-
-
Dmitry Lenev authored
WITH READ LOCK and FLUSH TABLES <list> WITH READ LOCK are incompatible", which adds information about waits caused by FLUSH TABLES statement to deadlock detector in MDL subsystem. Remove API supporting caching of pointers to TABLE_SHARE object in MDL subsystem and all code related to it. The problem was that locking requirements of code implementing this API conflicted with locking requirements of code which adds information about waits caused by flushes to deadlock detector in MDL subsystem (the former needed to lock LOCK_open or its future equivalent while having write-lock on MDL_lock's rwlock, and the latter needs to be able to read-lock MDL_lock rwlock while owning LOCK_open or its future equivalent). Since caching of pointers to TABLE_SHARE objects in MDL subsystem didn't bring expected performance benefits we decided to remove caching API rather than try to come up with some complex solution for this problem.
-
- 08 Jul, 2010 1 commit
-
-
Davi Arnaut authored
Essentially, the problem is that safemalloc is excruciatingly slow as it checks all allocated blocks for overrun at each memory management primitive, yielding a almost exponential slowdown for the memory management functions (malloc, realloc, free). The overrun check basically consists of verifying some bytes of a block for certain magic keys, which catches some simple forms of overrun. Another minor problem is violation of aliasing rules and that its own internal list of blocks is prone to corruption. Another issue with safemalloc is rather the maintenance cost as the tool has a significant impact on the server code. Given the magnitude of memory debuggers available nowadays, especially those that are provided with the platform malloc implementation, maintenance of a in-house and largely obsolete memory debugger becomes a burden that is not worth the effort due to its slowness and lack of support for detecting more common forms of heap corruption. Since there are third-party tools that can provide the same functionality at a lower or comparable performance cost, the solution is to simply remove safemalloc. Third-party tools can provide the same functionality at a lower or comparable performance cost. The removal of safemalloc also allows a simplification of the malloc wrappers, removing quite a bit of kludge: redefinition of my_malloc, my_free and the removal of the unused second argument of my_free. Since free() always check whether the supplied pointer is null, redudant checks are also removed. Also, this patch adds unit testing for my_malloc and moves my_realloc implementation into the same file as the other memory allocation primitives.
-
- 02 Jul, 2010 1 commit
-
-
Davi Arnaut authored
Apart strict-aliasing warnings, fix the remaining warnings generated by GCC 4.4.4 -Wall and -Wextra flags. One major source of warnings was the in-house function my_bcmp which (unconventionally) took pointers to unsigned characters as the byte sequences to be compared. Since my_bcmp and bcmp are deprecated functions whose only difference with memcmp is the return value, every use of the function is replaced with memcmp as the special return value wasn't actually being used by any caller. There were also various other warnings, mostly due to type mismatches, missing return values, missing prototypes, dead code (unreachable) and ignored return values.
-
- 01 Jul, 2010 2 commits
-
-
Dmitry Lenev authored
DROP/ALTER/CREATE DATABASE with open HANDLER". Remove wait_for_condition() which became unused after database locks were replaced with MDL scoped locks. If one needs functionality provided by this call one can always use THD::enter_cond()/exit_cond() methods. Also removed an unused include from sql_db.cc and updated comment describing one of used includes to reflect current situation.
-
Jon Olav Hauglid authored
DATABASE with open HANDLER" Remove LOCK_create_db, database name locks, and use metadata locks instead. This exposes CREATE/DROP/ALTER DATABASE statements to the graph-based deadlock detector in MDL, and paves the way for a safe, deadlock-free implementation of RENAME DATABASE. Database DDL statements will now take exclusive metadata locks on the database name, while table/view/routine DDL statements take intention exclusive locks on the database name. This prevents race conditions between database DDL and table/view/routine DDL. (e.g. DROP DATABASE with concurrent CREATE/ALTER/DROP TABLE) By adding database name locks, this patch implements WL#4450 "DDL locking: CREATE/DROP DATABASE must use database locks" and WL#4985 "DDL locking: namespace/hierarchical locks". The patch also changes code to use init_one_table() where appropriate. The new lock_table_names() function requires TABLE_LIST::db_length to be set correctly, and this is taken care of by init_one_table(). This patch also adds a simple template to help work with the mysys HASH data structure. Most of the patch was written by Konstantin Osipov.
-
- 29 Jun, 2010 2 commits
-
-
Konstantin Osipov authored
Bug#52114 and Bug#50788. The bugs themselves are regressions that are introduced by an incomplete fix for Bug#36171 and will not be pushed.
-
Konstantin Osipov authored
Remove mysql_lock_have_duplicate(), since now we always have TABLE_LIST objects for MyISAMMRG children in lex->query_tables and keep it till the end of the statement (sub-statement).
-