mariadb

Commit Graph

Author	SHA1	Message	Date
Sergei Golubchik	69cb13602d	another fix for --innodb-trx* name conflict	14 years ago
Sergei Golubchik	c3c14a069b	another fix for --innodb-trx* name conflict	14 years ago
Igor Babaev	fba0ead63e	Supported extended keys (MWL #247 ) for innodb_plugin.	14 years ago
Sergei Golubchik	c39877071a	overlay support for mysql-test-run and mysqltest mysql-test-run auto-disables all optional plugins. mysql-test/include/default_client.cnf: no @OPT.plugindir anymore mysql-test/include/default_mysqld.cnf: don't disable plugins manually - mtr can do it better mysql-test/suite/innodb/t/innodb_bug47167.test: mtr now uses suite-dir as an include path mysql-test/suite/innodb/t/innodb_file_format.test: mtr now uses suite-dir as an include path mysql-test/t/partition_binlog.test: this test uses partitions storage/example/mysql-test/mtr/t/source.result: update results. as mysqltest includes the correct overlayed include storage/innobase/handler/ha_innodb.cc: the assert is wrong	14 years ago
Vasil Dimov	1c4fd3bb54	Fix Bug#11754376 45976: INNODB LOST FILES FOR TEMPORARY TABLES ON GRACEFUL SHUTDOWN During startup mysql picks up .frm files from the tmpdir directory and tries to drop those tables in the storage engine. The problem is that when tmpdir ends in / then ha_innobase::delete_table() is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it to "/#sql123" and calls row_drop_table_for_mysql() which of course fails to delete the table entry from the InnoDB dictionary cache. ha_innobase::delete_table() returns an error but nevertheless mysql wipes away the .frm file and the entry in the InnoDB dictionary cache remains orphaned with no easy way to remove it. The "no easy" way to remove it is to create a similar temporary table again, copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file after restart and will try to issue drop table for "/var/tmp/#sql123" (notice do double slash), ha_innobase::delete_table() will normalize it to "tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the table entry from the dictionary cache. The solution is to fix normalize_table_name_low() to normalize things like "/var/tmp//table" correctly to "tmp/table". This patch also adds a test function which invokes normalize_table_name_low() with various inputs to make sure it works correctly and a mtr test that calls this test function. Reviewed by: Marko (http://bur03.no.oracle.com/rb/r/929/)	14 years ago
Marko Mäkelä	1fbbacfea5	ha_innobase::records_in_range(): Remove a debug assertion that prohibits an open range (full table). This assertion catches unnecessary calls to this method, but such calls are not harming correctness.	14 years ago
Sergei Golubchik	baca1a40e9	enable test cases for bugs fixed in xtradb. disable test cases for bugs not fixed in xtradb. mysql-test/suite/innodb/t/innodb-lock.test: instead of disabling the test in disabled.def (hoping that somebody someday will enable it), skip it only for xtradb (not for innodb), and only for the current xtradb version. the test will enable itself automatically on the next xtradb merge mysql-test/suite/innodb/t/innodb_cmp_drop_table.test: instead of disabling the test in disabled.def (hoping that somebody someday will enable it), skip it only for xtradb (not for innodb), and only for the current xtradb version. the test will enable itself automatically on the next xtradb merge mysql-test/suite/innodb/t/innodb_corrupt_bit.test: fix the error number storage/innobase/handler/ha_innodb.cc: fix the error number storage/xtradb/handler/ha_innodb.cc: fix the error number	14 years ago
Annamalai Gurusami	020f3914a2	Bug #11765438 58406: ISSUES WITH COPYING PARTITIONED INNODB TABLES FROM LINUX TO WINDOWS This problem was already fixed in mysql-trunk as part of bug #11755924. I am backporting the fix to mysql-5.1.	14 years ago
Yasufumi Kinoshita	115f5e8551	Bug#12400341 INNODB CAN LEAVE ORPHAN IBD FILES AROUND If we meet DB_TOO_MANY_CONCURRENT_TRXS during the execution tab_create_graph from row_create_table_for_mysql(), .ibd file for the table should be created already but was not deleted for the error handling. rb:875 approved by Jimmy Yang	14 years ago
Vasil Dimov	cb80ad09da	Partial fix for Bug#11764622 57480: MEMORY LEAK WHEN HAVING 256+ TABLES Port vasil.dimov@oracle.com-20111205083046-jtgi1emlvtfnjatt from mysql-trunk	14 years ago
Vasil Dimov	b7b9a4e810	Partial fix for Bug#11764622 57480: MEMORY LEAK WHEN HAVING 256+ TABLES Port vasil.dimov@oracle.com-20111205082756-wtlg8isyn4yohyny from mysql-trunk	14 years ago
Annamalai Gurusami	ad84fb5c37	Bug #13117023 : Innodb increments handler_read_key when it should not The counter handler_read_key (SSV::ha_read_key_count) is incremented incorrectly. The mysql server maintains a per thread system_status_var (SSV) object. This object contains among other things the counter SSV::ha_read_key_count. The purpose of this counter is to measure the number of requests to read a row based on a key (or the number of index lookups). This counter was wrongly incremented in the ha_innobase::innobase_get_index(). The fix removes this increment statement (for both innodb and innodb_plugin). The various callers of the innobase_get_index() was checked to determine if anybody must increment this counter (if they first call innobase_get_index() and then perform an index lookup). It was found that no caller of innobase_get_index() needs to worry about the SSV::ha_read_key_count counter.	14 years ago
Vasil Dimov	de479ab3b6	Followup to vasil.dimov@oracle.com-20111118115710-1xlezv0nbjz6s2ps Fix merge issues after discussing with Marko.	14 years ago
Marko Mäkelä	a0a51251e4	Bug#11759688 52020: InnoDB can still deadlock on just INSERT...ON DUPLICATE KEY a.k.a. Bug#7975 deadlock without any locking, simple select and update Bug#7975 was reintroduced when the storage engine API was made pluggable in MySQL 5.1. Instead of looking at thd->lex directly, we rely on handler::extra(). But, we were looking at the wrong extra() flag, and we were ignoring the TRX_DUP_REPLACE flag in places where we should obey it. innodb_replace.test: Add tests for hopefully all affected statement types, so that bug should never ever resurface. This kind of tests should have been added when fixing Bug#7975 in MySQL 5.0.3 in the first place. rb:806 approved by Sunny Bains	14 years ago
Marko Mäkelä	b003b6294c	Add debug assertions to catch Bug#13345378 earlier. In all callers of row_sel_convert_mysql_key_to_innobase(), assert that the converted key is empty or nonempty when it should be.	14 years ago
Marko Mäkelä	013ba71dfd	Bug#13002783 PARTIALLY UNINITIALIZED CASCADE UPDATE VECTOR In the ON UPDATE CASCADE clause of FOREIGN KEY constraints, the calculated update vector was not fully initialized. This bug was introduced in the InnoDB Plugin when implementing support for ROW_FORMAT=DYNAMIC. Additionally, the data type information was not initialized, but apparently it has never been needed in this case. Nevertheless, it is not good programming practice to pass uninitialized values around. calc_row_difference(): Declare the update field uninitialized in Valgrind. Copy the data type information as well, except when the field is SQL NULL. In the built-in InnoDB, initialize ufield->extern_storage = FALSE (an initialization bug that had gone unnoticed this far). The InnoDB Plugin and later have this flag to dfield_t and have always initialized it properly. row_ins_cascade_calc_update_vec(): Reduce the scope of some pointers. Initialize orig_len. (This caused the bug in InnoDB Plugin and later.) row_ins_foreign_check_on_constraint(): Simplify a condition. Declare the update vector uninitialized. rb:771 approved by Jimmy Yang	14 years ago
Jimmy Yang	d1a80e6ad7	Fix Bug #12885783 - BLOCK LOADING TABLE WITH LARGE COLLATION NUMBER FROM 5.6 SERVER rb://747 approved by Marko	14 years ago
Marko Mäkelä	247ada63af	Bug#12547647 UPDATE LOGGING COULD EXCEED LOG PAGE SIZE This fix was accidentally pushed to mysql-5.1 after the 5.1.59 clone-off in bzr revision id marko.makela@oracle.com-20110829081642-z0w992a0mrc62s6w with the fix of Bug#12704861 Corruption after a crash during BLOB update but not merged to mysql-5.5 and upwards. In the Barracuda formats, the clustered index record no longer contains a prefix of off-page columns. Because of this, the undo log must contain these prefixes, so that purge and multi-versioning will continue to work. However, this also means that an undo log record can become too big to fit in an undo log page. (It is a limitation of the undo log that undo records cannot span across multiple pages.) In case the checks for undo log size fail when CREATE TABLE or CREATE INDEX is executed, we need a fallback that blocks a modification operation when the undo log record would exceed the maximum size. trx_undo_free_last_page_func(): Renamed from trx_undo_free_page_in_rollback(). Define the trx_t parameter only in debug builds. trx_undo_free_last_page(): Wrapper for trx_undo_free_last_page_func(). Pass the trx_t parameter only in debug builds. trx_undo_truncate_end_func(): Renamed from trx_undo_truncate_end(). Define the trx_t parameter only in debug builds. Rewrite a for(;;) loop as a while loop for clarity. trx_undo_truncate_end(): Wrapper for from trx_undo_truncate_end_func(). Pass the trx_t parameter only in debug builds. trx_undo_erase_page_end(): Return TRUE if the page was non-empty to begin with. Refuse to erase empty pages. trx_undo_report_row_operation(): If the page for which the undo log was too big was empty, free the undo page and return DB_TOO_BIG_RECORD. rb:749 approved by Inaam Rana	14 years ago
Jimmy Yang	d9c3d35437	In innobase_format_name() we should call innobase_convert_name() with "!is_index_name" instead of "is_index_name", so the table name in the error message would not be formated as index name.	14 years ago
Jimmy Yang	95fa7fab3b	Fix bug #11830883 , SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES. Also addressed issues in bug #11745133, where we could mark a table corrupted instead of crashing the server when found a corrupted buffer/page if the table created with innodb_file_per_table on.	14 years ago
Mats Kindahl	cf5e5f837a	Merging into mysql-5.5.16-release.	15 years ago
Marko Mäkelä	f2f4b19678	Bug#12626794 61240: UNUSED FUNCTIONS ...	15 years ago
Marko Mäkelä	8c988dc61b	Bug#12699505 Memory leak in row_create_index_for_mysql() DB_COL_APPEARS_TWICE_IN_INDEX: Remove. This condition is already checked and reported by MySQL before passing the index definition to the storage engine. row_create_index_for_mysql(): Remove the redundant check for DB_COL_APPEARS_TWICE_IN_INDEX. When enforcing the column prefix index limit, invoke dict_mem_index_free(index) to plug the memory leak. In the loop, use index->n_def instead of dict_index_get_n_fields(index), because the latter would be 0 for indexes that have not been copied to the data dictionary cache. innodb-use-sys-malloc.test: Add test cases for attempting to trigger the error checks in row_create_index_for_mysql(). Before MySQL 5.5 and WL#5743, the leak is only reproducible if ha_innobase::max_supported_key_part_length() returned a higher limit than the one used in row_create_index_for_mysql(). In MySQL 5.5 and later, the leak is reproducible with innodb_large_prefix=true. rb:688 approved by Jimmy Yang	15 years ago
Vladislav Vaintroub	4171483b53	Backport Fix for Bug#24509 - 2048 file descriptor limit on windows needs increasing. The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open file is stored in the my_file_info struct, along with a flag for append mode (because the Windows API does not support opening files in append mode in all cases) The default max open files has been increased to 16384 and can be increased further by setting --max-open-files=<value> during the server start. Noteworthy benefit of this patch is that it removes limits from the table_cache size - allowing for more simultaneus users	15 years ago
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
Sergei Golubchik	c1a92f9cae	innodb compatibility fix	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
unknown	6ed10ee5dd	Bug#60309 - Bug#12356829: MYSQL 5.5.9 FOR MAC OSX HAS BUG WITH FOREIGN KEY CONSTRAINTS The innoDB global variable srv_lower_case_table_names is set to the value of lower_case_table_names declared in mysqld.h server in ha_innodb.cc. Since this variable can change at runtime, it is reset for each handler call to ::create, ::open, ::rename_table & ::delete_table. But it is possible for tables to be implicitly opened before an explicit handler call is made when an engine is first started or restarted. I was able to reproduce that with the testcase in this patch on a version of InnoDB from 2 weeks ago. It seemed like the change buffer entries for the secondary key was getting put into pages after the restart. (But I am not sure, I did not write down the call stack while it was reproducing.) In the current code, the implicit open, which is actually a call to dict_load_foreigns(), does not occur with this testcase. The change is to replace srv_lower_case_table_names by an interface function in innodb.cc that retrieves the server global variable when it is needed.	15 years ago
Sergei Golubchik	0accbd0364	lots of post-merge changes	15 years ago
Marko Mäkelä	12fbe05c6a	Bug #11760042 - 52409: Assertion failure: long semaphore wait In ha_innobase::create(), we check some things while holding an exclusive lock on the data dictionary. Defer the locking and the creation of transactions until after the checks have passed. The THDVAR could hang due to a mutex wait (see Bug #11750569 - 41163: deadlock in mysqld: LOCK_global_system_variables and LOCK_open), and we want to avoid waiting while holding InnoDB mutexes. innobase_index_name_is_reserved(): Replace the parameter trx_t with THD, so that the test can be performed before starting an InnoDB transaction. We only needed trx->mysql_thd. ha_innobase::create(): Create transaction and lock the data dictionary only after passing the basic tests. create_table_def(): Move the IS_MAGIC_TABLE_AND_USER_DENIED_ACCESS check to ha_innobase::create(). Assign to srv_lower_case_table_names while holding dict_sys->mutex. ha_innobase::delete_table(), ha_innobase::rename_table(), innobase_rename_table(): Assign srv_lower_case_table_names as late as possible. Here, the variable is not necessarily protected by dict_sys->mutex. ha_innobase::add_index(): Invoke innobase_index_name_is_reserved() and innobase_check_index_keys() before allocating anything. rb:618 approved by Jimmy Yang	15 years ago
Marko Mäkelä	0ff2a182b6	Bug #11766513 - 59641: Prepared XA transaction in system after hard crash causes future shutdown hang InnoDB would hang on shutdown if any XA transactions exist in the system in the PREPARED state. This has been masked by the fact that MySQL would roll back any PREPARED transaction on shutdown, in the spirit of Bug #12161 Xa recovery and client disconnection. [mysql-test-run] do_shutdown_server: Interpret --shutdown_server 0 as a request to kill the server immediately without initiating a shutdown procedure. xid_cache_insert(): Initialize XID_STATE::rm_error in order to avoid a bogus error message on XA ROLLBACK of a recovered PREPARED transaction. innobase_commit_by_xid(), innobase_rollback_by_xid(): Free the InnoDB transaction object after rolling back a PREPARED transaction. trx_get_trx_by_xid(): Only consider transactions whose trx->is_prepared flag is set. The MySQL layer seems to prevent attempts to roll back connected transactions that are in the PREPARED state from another connection, but it is better to play it safe. The is_prepared flag was introduced in the InnoDB Plugin. trx_n_prepared: A new counter, counting the number of InnoDB transactions in the PREPARED state. logs_empty_and_mark_files_at_shutdown(): On shutdown, allow trx_n_prepared transactions to exist in the system. trx_undo_free_prepared(), trx_free_prepared(): New functions, to free the memory objects of PREPARED transactions on shutdown. This is not needed in the built-in InnoDB, because it would collect all allocated memory on shutdown. The InnoDB Plugin needs this because of innodb_use_sys_malloc. trx_sys_close(): Invoke trx_free_prepared() on all remaining transactions.	15 years ago
Sergei Golubchik	8de6199b16	lp:743017 Diverging results with TIME(3) and ranges depending on the execution plan in 5.1-micro rewrite get_innobase_type_from_mysql_type() to use types as reported by the Field objects, instead of relying on ad-hoc assumptions.	15 years ago
Marko Mäkelä	85dbe88d2f	Bug#11766305 - 59392: Remove thr0loc.c and ibuf_inside() [part 4 of 4] ibuf_inside(), ibuf_enter(), ibuf_exit(): Add the parameter mtr. The flag is no longer kept in the thread-local storage but in the mini-transaction (mtr->inside_ibuf). mtr_start(): Clean up the comment and remove the unused return value. mtr_commit(): Assert !ibuf_inside(mtr) in debug builds. ibuf_mtr_start(): Like mtr_start(), but sets the flag. ibuf_mtr_commit(), ibuf_btr_pcur_commit_specify_mtr(): Wrappers that assert ibuf_inside(). buf_page_get_zip(), buf_page_init_for_read(), buf_read_ibuf_merge_pages(), fil_io(), ibuf_free_excess_pages(), ibuf_contract_ext(): Remove assertions on ibuf_inside(), because a mini-transaction is not available. buf_read_ahead_linear(): Add the parameter inside_ibuf. ibuf_restore_pos(): When this function returns FALSE, it commits mtr and must therefore do ibuf_exit(mtr). ibuf_delete_rec(): This function commits mtr and must therefore do ibuf_exit(mtr). ibuf_rec_get_page_no(), ibuf_rec_get_space(), ibuf_rec_get_info(), ibuf_rec_get_op_type(), ibuf_build_entry_from_ibuf_rec(), ibuf_rec_get_volume(), ibuf_get_merge_page_nos(), ibuf_get_volume_buffered_count(), ibuf_get_entry_counter_low(): Add the parameter mtr in debug builds, for asserting ibuf_inside(mtr). rb:585 approved by Sunny Bains	15 years ago
MySQL Build Team	97d7805005	Per Jon Olav, change needed for Bug#11784056	15 years ago
Jon Olav Hauglid	fc6ef378d4	Bug#11815600 [ERROR] INNODB COULD NOT FIND INDEX PRIMARY KEY NO 0 FOR TABLE IN ERROR LOG With the changes made by the patches for Bug#11751388 and Bug#11784056, concurrent reads are allowed while secondary indexes are created in InnoDB. This means that the metadata lock on the affected table is not upgraded to exclusive until the .FRM is updated at the end of ALTER TABLE processing. The problem was that if this lock upgrade failed for some reason (e.g. timeout), the index information in the server and inside InnoDB would be out of sync. This would happen since the add index operation already was committed inside InnoDB but the table metadata inside the server had not been updated yet. This patch fixes the problem by (for now) reverting the effects of the patches for Bug#11751388 and Bug#11784056. Concurrent reads will now again be blocked during creation of secondary indexes in InnoDB. Test case added to innodb_mysql_lock.test.	15 years ago
Jon Olav Hauglid	5e32755e4c	Bug #11784056 ENABLE CONCURRENT READS WHILE CREATING NON-PRIMARY UNIQUE INDEX USING INNODB This patch adds the HA_INPLACE_ADD_UNIQUE_INDEX_NO_WRITE capability flag to InnoDB, indicating that concurrent reads can be allowed while non-primary unique indexes are created. This is an follow-up to Bug #11751388 which enabled concurrent reads when creating non-primary non-unique indexes. Test case added to innodb_mysql_sync.test.	15 years ago
Vasil Dimov	8d8784e930	Use plugin_author also for the InnoDB SE plugin Move the const variable plugin_author to a common header file that is being included by both ha_innodb.cc and i_s.cc	15 years ago
Jimmy Yang	56845ed3b4	Fix Bug #11765975 __FILE__ macros expanded to full path instead of relative in CMake builds rb://600 approved by Sunny Bains	15 years ago
Sunny Bains	f91ce0413b	Revert the max value of innodb_purge_batch_size to 5000.	15 years ago
Sunny Bains	b3c9cc6f21	Bug #11766227 : InnoDB purge lag much worse for 5.5.8 versus 5.1 Bug #11766501: Multiple RBS break the get rseg with mininum trx_t::no code during purge Bug# 59291 changes: Main problem is that truncating the UNDO log at the completion of every trx_purge() call is expensive as the number of rollback segments is increased. We truncate after a configurable amount of pages. The innodb_purge_batch_size parameter is used to control when InnoDB does the actual truncate. The truncate is done once after 128 (or TRX_SYS_N_RSEGS iterations). In other words we truncate after purge 128 * innodb_purge_batch_size. The smaller the batch size the quicker we truncate. Introduce a new parameter that allows how many rollback segments to use for storing REDO information. This is really step 1 in allowing complete control to the user over rollback space management. New parameters: i) innodb_rollback_segments = number of rollback_segments to use (default is now 128) dynamic parameter, can be changed anytime. Currently there is little benefit in changing it from the default. Optimisations in the patch. i. Change the O(n) behaviour of trx_rseg_get_on_id() to O(log n) Backported from 5.6. Refactor some of the binary heap code. Create a new include/ut0bh.ic file. ii. Avoid truncating the rollback segments after every purge. Related changes that were moved to a separate patch: i. Purge should not do any flushing, only wait for space to be free so that it only does purging of records unless it is held up by a long running transaction that is preventing it from progressing. ii. Give the purge thread preference over transactions when acquiring the rseg->mutex during commit. This to avoid purge blocking unnecessarily when getting the next rollback segment to purge. Bug #11766501 changes: Add the rseg to the min binary heap under the cover of the kernel mutex and the binary heap mutex. This ensures the ordering of the min binary heap. The two changes have to be committed together because they share the same that fixes both issues. rb://567 Approved by: Inaam Rana.	15 years ago
Jon Olav Hauglid	e99f2b1c4e	Bug #42230 during add index, cannot do queries on storage engines that implement add_index The problem was that ALTER TABLE blocked reads on an InnoDB table while adding a secondary index, even if this was not needed. It is only needed for the final step where the .frm file is updated. The reason queries were blocked, was that ALTER TABLE upgraded the metadata lock from MDL_SHARED_NO_WRITE (which blocks writes) to MDL_EXCLUSIVE (which blocks all accesses) before index creation. The way the server handles index creation, is that storage engines publish their capabilities to the server and the server determines which of the following three ways this can be handled: 1) build a new version of the table; 2) change the existing table but with exclusive metadata lock; 3) change the existing table but without metadata lock upgrade. For InnoDB and secondary index creation, option 3) should have been selected. However this failed for two reasons. First, InnoDB did not publish this capability properly. Second, the ALTER TABLE code failed to made proper use of the information supplied by the storage engine. A variable need_lock_for_indexes was set accordingly, but was not later used. This patch fixes this problem by only doing metadata lock upgrade before index creation/deletion if this variable has been set. This patch also changes some of the related terminology used in the code. Specifically the use of "fast" and "online" with respect to ALTER TABLE. "Fast" was used to indicate that an ALTER TABLE operation could be done without involving a temporary table. "Fast" has been renamed "in-place" to more accurately describe the behavior. "Online" meant that the operation could be done without taking a table lock. However, in the current implementation writes are always prohibited during ALTER TABLE and an exclusive metadata lock is held while updating the .frm, so ALTER TABLE is not completely online. This patch replaces "online" with "in-place", with additional comments indicating if concurrent reads are allowed during index creation/deletion or not. An important part of this update of terminology is renaming of the handler flags used by handlers to indicate if index creation/deletion can be done in-place and if concurrent reads are allowed. For example, the HA_ONLINE_ADD_INDEX_NO_WRITES flag has been renamed to HA_INPLACE_ADD_INDEX_NO_READ_WRITE, while HA_ONLINE_ADD_INDEX is now HA_INPLACE_ADD_INDEX_NO_WRITE. Note that this is a rename to clarify current behavior, the flag values have not changed and no flags have been removed or added. Test case added to innodb_mysql_sync.test.	15 years ago
Jimmy Yang	9cd4d49840	Fix Bug#30423 "InnoDBs treatment of NULL in index stats causes bad "rows examined" estimates". This change implements "innodb_stats_method" with options of "nulls_equal", "nulls_unequal" and "null_ignored". rb://553 approved by Marko	15 years ago
Mikael Ronstrom	7dae4282d4	BUG#59392, removed thread local storage use in MySQL Threads by storing ibuf_inside indicator in MTR object instead	15 years ago
Vasil Dimov	211c56c022	Fix InnoDB style after mikael@dator8-20101217205840-i7ltx8m6z3uc42kh	15 years ago
Vasil Dimov	909d7c299c	PS-instrument the array of latches (rw locks) dict_table_stats_latches[]. This adds 64 new rows to performance_schema.rwlock_instances. This patch will make perfschema.binlog_mix perfschema.binlog_row tests fail, but they will be fixed by http://lists.mysql.com/commits/127862 Approved by: Jimmy (rb://554)	15 years ago
Mikael Ronstrom	247ecb7597	BUG#59013, make partition handler not miss HA_STATUS_NO_LOCK, add HA_STATUS_VARIABLE_EXTRA to remove InnoDB bottleneck	15 years ago
Jimmy Yang	9838f48476	Fix Bug #58643 InnoDB: too long table name rb://531 approved by Sunny Bains	15 years ago
unknown	2dde698e0e	Bug#55222 - RB://517 - Approved by Sunny InnoDB does not attempt to handle lower_case_table_names == 2 when looking up foreign table names and referenced table name. It turned that server variable into a boolean and ignored the possibility of it being '2'. The setting lower_case_table_names == 2 means that it should be stored and displayed in mixed case as given, but compared internally in lower case. Normally the server deals with this since it stores table names. But InnoDB stores referential constraints for the server, so it needs to keep track of both lower case and given names. This solution creates two table name pointers for each foreign and referenced table name. One to display the name, and one to look it up. Both pointers point to the same allocated string unless this setting is 2. So the overhead added is not too much. Two functions are created in dict0mem.c to populate the ..._lookup versions of these pointers. Both dict_mem_foreign_table_name_lookup_set() and dict_mem_referenced_table_name_lookup_set() are called 5 times each.	15 years ago
unknown	4018c39361	RB://518 approved by Jimmy Yang and Sunny bains Code cleanup after changes for Bug 56628. The general approach for InnoDB is to make a reference to each enum value whenever it is used in a switch statement. In addition, no default case should be used for switch statements on enum types. This assures that if there is ever any change in the enum values, the switch will need to change to reflect it since a compiler warning will occur. In this case, the enum row_type is declared in handler.h and could be changed for another storage engine. If so, a warning will occur in the InnoDB build. Other changes; * This patch uses 2 macros to help consolidate warning messages that need to occur twice in the single switch for row_format. * Using row_format as the variable name to distinguish it from the enum type. * Function declaration format correction.	15 years ago

1 2 3 4 5 ...

429 Commits (867296c3edc4502093f7b706e7ac4c1670aa9515)