mariadb

Tree: 02e07e3b51

Author	SHA1	Message	Date
Jon Olav Hauglid	9b076952ec	Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING SECONDARY INDEX IN INNODB The patches for Bug#11751388 and Bug#11784056 enabled concurrent reads while creating secondary indexes in InnoDB. However, they introduced a regression. This regression occured if ALTER TABLE failed after the index had been added, for example during the lock upgrade needed to update .FRM. If this happened, InnoDB and the server got out of sync with regards to which indexes actually existed. Therefore the patch for Bug#11815600 again disabled concurrent reads. This patch re-enables concurrent reads. The original regression is fixed by splitting the ADD INDEX operation into two parts. First the new index is created but not made active. This is done while concurrent reads are allowed. The second part of the operation makes the index active (or reverts the change). This is done after lock upgrade, which prevents the original regression. In order to implement this change, the patch changes the storage API for in-place index creation. handler::add_index() is split into two functions, handler_add_index() and handler::final_add_index(). The former for creating indexes without making them visible and the latter for commiting (i.e. making visible) new indexes or reverting the changes. Large parts of this patch were written by Marko Mäkelä. Test case added to innodb_mysql_lock.test.	15 years ago
Jimmy Yang	9e2b7fa7d5	Implement worklog #5743 InnoDB: Lift the limit of index key prefixes. With this change, the index prefix column length lifted from 767 bytes to 3072 bytes if "innodb_large_prefix" is set to "true". rb://603 approved by Marko	15 years ago
Marko Mäkelä	53e9aabe12	Bug#12606344 - ADD VALGRIND DIAGNOSTICS TO MTR_START, MTR_COMMIT mtr_start(): Declare the mtr memory area uninitialized in Valgrind before initializing the fields. mtr_commit(): Declare everything uninitialized except mtr->start_lsn, mtr->end_lsn and mtr->state.	15 years ago
Davi Arnaut	c7d2ec7dd5	Bug#11766349 - 59443: query_cache_debug.test is occasionally very slow The test case problem stemmed from the fact that a debug sync signal is a global variable that persists until overwritten by a new signal. This means that if two different signals are raised in sequence, a thread waiting for the first signal might miss it if the second signal sets the global variable before the thread wakes up. The solution is to deliver a subsequent signal only after the waiting thread has received it. mysql-test/t/query_cache_debug.test: Wait for signal to be delivered.	15 years ago
Bjorn Munch	ec0b030f26	Bug #12604711 MTR SHOULD READ PLUGIN.DEFS FILES FROM IMPORTED FEATURE TREES Added reading from plugin.defs files under plugins/*	15 years ago
Davi Arnaut	9f6ec59980	Merge of mysql-5.1 into mysql-5.5.	15 years ago
Davi Arnaut	9b68760fd6	Bug#12563279: REGRESSION IN HANDLING PRE-4.1 AUTHENTICATION PACKET The problem is that clients implementing the 4.0 version of the protocol (that is, mysql-4.0) do not null terminate a string at the end of the authentication packet. These clients denote the end of the string with the end of the packet. Although this goes against the documented (see MySQL Internals ClientServer Protocol wiki) description of the protocol, these old clients still need to be supported. The solution is to support the documented and actual behavior of the clients. If a client is using the pre-4.1 version of the protocol, the end of a string in the authentication packet can either be denoted with a null character or by the end of the packet. This restores backwards compatibility with old clients implementing either the documented or actual behavior. sql/password.c: The scrambled message, as provided by the user, might not be properly null terminated. If this is the case, uninitialized memory past the end of the buffer could theoretically be accessed. To ensure that this is never the case, copy the scrambled message over to a null terminated auxiliar buffer. sql/sql_connect.cc: Use different execution paths to read strings depending on the protocol being used. If version 4.0 of the protocol is used, end of string can be denoted with a NUL character or by the end of the packet. If there are not enough bytes left after the current position of the buffer to satisfy the current string, the string is considered to be empty. This is required because old clients do not send the password string field if the password is empty.	15 years ago
Davi Arnaut	f3e114291c	Null merge of mysql-5.1 into mysql-5.5.	15 years ago
Bjorn Munch	94f96bc472	Bug #12598603 HAVE COLLECTIONS FILES IN FEATURE TREES AUTO-APPENDED TO COMMON FILES Do this in the common plugin.cmake but only if running in PB2 (If done in manual builds it would create a bzr diff)	15 years ago
Dmitry Shulga	c34a99b8b9	Manual-merge of patch for bug#12546938 from mysql-5.1->mysql-5.5	15 years ago
Davi Arnaut	0509883160	BUG 11763056 - 55721: AIX 5.1.50 build failing, cannot locate bzero The problem is that although AIX implements bzero, its prototype is not declared by default. Since AC_CHECK_FUNC(bzero) succeeds even though a prototype is not declared, this breaks compilation in C++ files where a prototype is required. The solution is to only use bzero if a prototype is also declared. configure.in: Check if bzero is declared. No need to specify the includes, unisted.h and strings.h are already part of AC_INCLUDES_DEFAULT.	15 years ago
Tatjana Azundris Nuernberg	20791d83de	build fixes for -Werror (11745920)	15 years ago
Dmitry Shulga	56a735b782	Fixed bug#12546938 (formerly known as 61005) - CREATE IF NOT EXIST EVENT will create multiple running events. A CREATE IF NOT EXIST on an event that existed and was enabled caused multiple instances of the event to run. Disabling the event didn't help. If the event was dropped, the event stopped running, but when created again, multiple instances of the event were still running. The only way to get out of this situation was to restart the server. The problem was that Event_db_repository::create_event() didn't return enough information to discriminate between situation when event didn't exist and was created and when event did exist and was not created (but a warning was emitted). As result in the latter case event was added to in-memory queue of events second time. And this led to unwarranted multiple executions of the same event. The solution is to add out-parameter to Event_db_repository::create_event() method which will signal that event was not created because it already exists and so it should not be added to the in-memory queue. mysql-test/r/events_bugs.result: Added results for test for Bug#12546938. mysql-test/t/events_bugs.test: Added test for Bug#12546938. sql/event_db_repository.cc: Event_db_repository::create_event was modified: set newly added out-parameter event_already_exists to true value if event wasn't created because event already existed and IF NOT EXIST clause was present. sql/event_db_repository.h: Added out-parameter 'event_already_exists' to create_event() method. sql/events.cc: Events::create_event was modified: insert new element into event queue only if event was actually created.	15 years ago
Anitha Gopi	8ae716e9a2	Automerge : Updating local tree	15 years ago
Dmitry Lenev	fecca34356	Fix for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". Attempt to update an InnoDB temporary table under LOCK TABLES led to assertion failure in both debug and production builds if this temporary table was explicitly locked for READ. The same scenario works fine for MyISAM temporary tables. The assertion failure was caused by discrepancy between lock that was requested on the rows of temporary table at LOCK TABLES time and by update operation. Since SQL-layer requested a read-lock at LOCK TABLES time InnoDB engine assumed that upcoming statements which are going to be executed under LOCK TABLES will only read table and therefore should acquire only S-lock. An update operation broken this assumption by requesting X-lock. Possible approaches to fixing this problem are: 1) Skip locking of temporary tables as locking doesn't make any sense for connection-local objects. 2) Prohibit changing of temporary table locked by LOCK TABLES ... READ. Unfortunately both of these approaches have drawbacks which make them unviable for stable versions of server. So this patch takes another approach and changes code in such way that LOCK TABLES for a temporary table will always request write lock. In 5.5 version of this patch switch from read lock to write lock is done on SQL-layer. mysql-test/suite/innodb/r/innodb_mysql.result: Added test for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". mysql-test/suite/innodb/t/innodb_mysql.test: Added test for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". sql/sql_parse.cc: Since a temporary table locked by LOCK TABLES can be updated even if it was only locked for read we always request TL_WRITE locks for such tables at LOCK TABLES time. This allows to avoid discrepancy between locks acquired at LOCK TABLES time and by a statement executed under LOCK TABLES. Such a discrepancy has caused problems for InnoDB storage engine. To support this change a part of code implementing LOCK TABLES has been moved to a helper function.	15 years ago
Dmitry Lenev	1db26385c1	Null-merged 5.1 version of fix for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK" into 5.5 tree. 5.5 version of fix will be committed and pushed separately.	15 years ago
Dmitry Lenev	861291f1ab	Fix for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". Attempt to update an InnoDB temporary table under LOCK TABLES led to assertion failure in both debug and production builds if this temporary table was explicitly locked for READ. The same scenario works fine for MyISAM temporary tables. The assertion failure was caused by discrepancy between lock that was requested on the rows of temporary table at LOCK TABLES time and by update operation. Since SQL-layer requested a read-lock at LOCK TABLES time InnoDB engine assumed that upcoming statements which are going to be executed under LOCK TABLES will only read table and therefore should acquire only S-lock. An update operation broken this assumption by requesting X-lock. Possible approaches to fixing this problem are: 1) Skip locking of temporary tables as locking doesn't make any sense for connection-local objects. 2) Prohibit changing of temporary table locked by LOCK TABLES ... READ. Unfortunately both of these approaches have drawbacks which make them unviable for stable versions of server. So this patch takes another approach and changes code in such way that LOCK TABLES for a temporary table will always request write lock. In 5.1 version of this patch switch from read lock to write lock is done inside of InnoDBs handler methods as doing it on SQL-layer causes compatibility troubles with FLUSH TABLES WITH READ LOCK. mysql-test/suite/innodb/r/innodb_mysql.result: Added test for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". mysql-test/suite/innodb/t/innodb_mysql.test: Added test for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". mysql-test/suite/innodb_plugin/r/innodb_mysql.result: Added test for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". mysql-test/suite/innodb_plugin/t/innodb_mysql.test: Added test for bug #11762012 - "54553: INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK". storage/innobase/handler/ha_innodb.cc: Assume that a temporary table locked by LOCK TABLES can be updated even if it was only locked for read and therefore an X-lock should be always requested for such tables. storage/innodb_plugin/handler/ha_innodb.cc: Assume that a temporary table locked by LOCK TABLES can be updated even if it was only locked for read and therefore an X-lock should be always requested for such tables.	15 years ago
Tatjana Azundris Nuernberg	e1b79597f6	auto-merge Bug#11745920	15 years ago
Sven Sandberg	add86aaddc	Merged BUG#12574820 from 5.1 to 5.5 Two conflicts resolved manually: Text conflict in sql/log.cc Text conflict in sql/mysqld.cc	15 years ago
Sven Sandberg	de3776819c	BUG#12574820: binlog.binlog_tmp_table timing out in daily and weekly trunk run Problem: MYSQL_BIN_LOG::reset_logs acquires mutexes in wrong order. The correct order is first LOCK_thread_count and then LOCK_log. This function does it the other way around. This leads to deadlock when run in parallel with a thread that takes the two locks in correct order. For example, a thread that disconnects will take the locks in the correct order. Fix: change order of the locks in MYSQL_BIN_LOG::reset_logs: first LOCK_thread_count and then LOCK_log. mysql-test/suite/binlog/r/binlog_reset_master.result: added result file mysql-test/suite/binlog/t/binlog_reset_master.test: Added test case that demonstrates deadlock because of wrong mutex order. The deadlock is between two threads: - RESET MASTER acquires mutexes in wrong order. - client thread shutdown code acquires mutexes in right order. Actually, this test case does not produce deadlock in 5.1, probably the client thread shutdown code does not hold both mutexes at the same time. However, the bug existed in 5.1 (mutexes are taken in the wrong order) so we push the test case to 5.1 too, to prevent future regressions. sql/log.cc: Change mutex acquisition to the correct order: first LOCK_thread_count, then LOCK_log. sql/mysqld.cc: Add debug code to synchronize test case.	15 years ago
Sergey Glukhov	9d42d36e7e	5.1 -> 5.5 merge	15 years ago
Sergey Glukhov	3efbf30457	Bug#12392636 ASSERTION FAILED: SCALE >= 0 && PRECISION > 0 && SCALE <= PRECISION Assertion happens due to missing NULL value check in Item_func_round::fix_length_and_dec() function. The fix: added NULL value check for second parameter. mysql-test/r/func_math.result: test case mysql-test/t/func_math.test: test case sql/item_func.cc: added NULL value check for second parameter.	15 years ago
Bjorn Munch	b5009ee6be	merge from 5.5-mtr	15 years ago
Tor Didriksen	c41e866357	Don't check for FIONREAD on windows. Execution of platforms tests are slow/flaky when building on windows. in PB:mysql-next-mr-opt-team on 2011-05-18 for win x86 debug_max, i see: -- Looking for FIONREAD -- Looking for FIONREAD - found and the build fails.	15 years ago
Anitha Gopi	037176b211	Bug#11759877 - Bug closed. Remove test from experimental group	15 years ago
Dmitry Shulga	876fd28402	Follow-up for patch for bug#11749345. sql/sql_show.cc: Restored DEBUG_SYNC point missed during merge 5.1->5.5	15 years ago
Bjorn Munch	0bb2424f4d	Increase test timeout for rpl.rpl_typeconv Not for test itself but because it procuces large number of warnings, and this may take >90s to filter on slow boxes	15 years ago
Anitha Gopi	607c8bfc16	Fixed formatting in disabled.def	15 years ago
Bjorn Munch	7f0b5b70ec	Bug #12590770 TEST SPECIFIC TIMEOUT SETTING DOES NOT APPLY TO "CHECK" OR "WARNINGS" Replace global check_timeout with one that calls testcase_timeout for the test	15 years ago
Anitha Gopi	09d1ca061f	Bug#12584161 : Test is failing consistently. Move nack to disabled list	15 years ago
Bjorn Munch	73d1992ef4	Bug #12586211 ENABLE GCOV BUILDS WITH CMAKE, INCLUDING PLUGINS Added --with-gcov option to configure.pl and use that from SETUP.sh	15 years ago
Mikael Ronström	f125f2994f	BUG#12578441, reintroduced thd->cleanup() in unlink_thd, removed by mistake, added private interface to this function	15 years ago
Bjorn Munch	e57de95f41	Bug #11750043 40340: USE GZIPPED CORE FILES TO SAVE SPACE Use [g]zip on core file if available, ignore if not Skip if running named test, and print a line saying what it compressed.	15 years ago
Marko Mäkelä	af3eff8da0	Bug#12584374 LOCK_VALIDATE TRIPS ASSERTION !BLOCK->PAGE.FILE_PAGE_WAS_FREE Fix a deadlock in the initial patch. lock_validate() must not hold the lock system mutex while s-latching a block, because some functions, such as lock_rec_convert_impl_to_expl(), may be already holding an x-latch on the block that lock_validate() is interested in while attempting to acquire the lock system mutex. This deadlock was not caught by UNIV_SYNC_DEBUG because of buf_block_dbg_add_level(block, SYNC_NO_ORDER_CHECK).	15 years ago
Anitha Gopi	7a73cb12eb	Autocommit - Updating local tree	15 years ago
Marko Mäkelä	0f95f99b03	Bug#12584374 LOCK_VALIDATE TRIPS ASSERTION !BLOCK->PAGE.FILE_PAGE_WAS_FREED lock_clust_rec_some_has_impl(), row_get_rec_trx_id(), lock_rec_queue_validate(), lock_table_other_has_incompatible(), lock_table_has_to_wait_in_queue(), lock_table_queue_validate(): Add const qualifiers. row_get_trx_id_offset(): Add const qualifiers. Keep the parameter rec only in UNIV_DEBUG builds. Inline the function. lock_rec_validate_page(): Take the buffer block as a parameter, to avoid a buf_page_get_gen() call in most cases. lock_rec_validate_page_low(): A version of lock_rec_validate_page() that assumes that the lock system mutexes are already being held. lock_rec_get_next_on_page_const(): A const variant of lock_rec_get_next_on_page(). lock_validate(): Do not release the lock system mutex while buffer-fixing the block for the lock_rec_validate_page() call. Releasing the mutex apparently caused the assertion failure. rb:665 approved by Sunny Bains	15 years ago
Anitha Gopi	3cf30b89ba	Automerge from mysql-5.1	15 years ago
Anitha Gopi	cce8a65843	BUG#12371924 # Bug is fixed. Move test out of experimental group	15 years ago
Bjorn Munch	b9937c4018	merge from 5.5 main	15 years ago
Horst.Hunger	41c13fb5c7	Merge of this test from trunk to 5.5 to have a successful weekly test on Windows.	15 years ago
Bjorn Munch	e0cf0819a9	Bug#11831031: MTR SHOULD FIND TEST SUITES FROM FEATURE TREES OUTSIDE MYSQL-TEST Backported from trunk-mtr	15 years ago
Marko Mäkelä	34e5d4740e	Backport an InnoDB Bug #58815 (Bug #11765812 ) work-around from mysql-trunk: ------------------------------------------------------------ revno 2876.244.305 revision id marko.makela@oracle.com-20110413082211-e6ouhjz5rmqxcqap parent marko.makela@oracle.com-20110413075948-kvytmc37ye1nt7d9 committer Marko Mäkelä <marko.makela@oracle.com> branch nick 5.6-innodb timestamp Wed 2011-04-13 11:22:11 +0300 message: Suppress the Bug #58815 (Bug #11765812) assertion failure. buf_page_get_gen(): Introduce BUF_GET_POSSIBLY_FREED for suppressing the check that the file page must not have been freed. btr_estimate_n_rows_in_range_on_level(): Pass BUF_GET_POSSIBLY_FREED and explain in the comments why this is needed and why it should be mostly harmless to ignore the problem. If InnoDB had always initialized all unused fields in data files, no problem would exist. This change does not fix the bug, it just "shoots the messenger". rb:647 approved by Jimmy Yang	15 years ago
Anitha Gopi	e4e738be59	Null merge from mysql-5.1	15 years ago
Anitha Gopi	099fbeb93d	Changed to Oracle bug numbers	15 years ago
Anitha Gopi	8dc7b927af	Upmerge from 5.1	15 years ago
Anitha Gopi	0464f964ad	Bug#11756699: Move test from disabled to experimental group	15 years ago
Anitha Gopi	f14b66d489	Bug#12584161 - Up merge from 5.1	15 years ago
Anitha Gopi	faf747bf52	Bug#12584161 - Moved test from disabled to experimental group	15 years ago
Luis Soares	79f8d024b8	BUG#12558519 Automerged bzr bundle from bug report into latest mysql-5.5.	15 years ago
Luis Soares	1e495b270f	BUG#12558519: RPL_TYPECONV PRODUCES VALGRIND STACK In RBR and in case of converting blob fields, the space allocated while unpacking into the conversion field was not freed after copying from it into the real field. We fix this by freeing the conversion field when the conversion table is not needed anymore (on close_tables_to_lock).	15 years ago

1 2 3 4 5 ...

69360 Commits (02e07e3b5195707031dc7399d2a2163b1dfd94a3) All Branches Search

69360 Commits (02e07e3b5195707031dc7399d2a2163b1dfd94a3)

All Branches